py37 test started to fail with latest virtualenv (20.16.4) as it
bundles setuptools 65.3.0, which causes installation problems under
py37. (Note: with py38 the problem does not occur).
This patch sets virtualenv<20.16.4 to unblock the gate as
virtualenv 20.16.3 bundles setuptools 63.4.1, with which py37 gate
works well.
Change-Id: I29beb88dd241af72397bf0dd1fc46c98a229425c
Also deletes obsolete playbook files for telemetry tests that have
been removed.
Change-Id: Ibbb811e988cc048e6c39a0c2336c716a1a0ddb30
(cherry picked from commit a5ae9f4aa0)
Currently, setting the '[oslo_messaging] direct_mandatory_flag' config
option to 'True' (the default) will result in a 'MessageUndeliverable'
exception being raised when sending a reply if a RabbitMQ queue is
missing [1]. It was the responsibility of the application to handle
this exception, however, many applications are not doing so. This has
resulted in a number of bug reports.
Start handling this error condition, using a retry loop to attempt to
resend the message and work around any temporary glitches. Since
attempting to send a reply will will no longer raise an exception,
there is little benefit in retaining the '[oslo_messaging]
direct_mandatory_flag' config option: users setting this to False will
simply not benefit from the retry logic and improved logging added
here. This option is already deprecated though and will be fully
removed in a future release.
[1] https://www.rabbitmq.com/channels.html
Change-Id: Id5cddbefbe24ef100f1cc522f44430df77d217cb
Closes-Bug: #1905965
(cherry picked from commit 4937949dff)
(cherry picked from commit 391ce7fc69)
It will not be possible to deactivate this functionality anymore.
Change-Id: I1cbafff03349f7da9224de46285707fbf2a81a68
(cherry picked from commit 2b89d97888)
(cherry picked from commit 06ad070cc6)
An IntOpt with a default of True is invalid. I'm a little surprised
this doesn't fail a defaults check somewhere, but it needs to be
fixed regardless.
Looking at where it is used, it appears the boolean type is correct.
This just changes the opt type to BoolOpt to match.
Change-Id: I01a38754a31c891f2b3b9c7f8135690693df5d13
Closes-Bug: 1909036
(cherry picked from commit b8f8b17030)
(cherry picked from commit a0329a3f86)
We facing errors related to the new pip resolver, this
topic was discussed on the ML and QA team proposed to
to test lower-constraints [1].
I propose to drop this test because the complexity and recurring pain needed
to maintain that now exceeds the benefits provided by this mechanismes.
Also removing lower constraints and related tox environment as they are
no longer needed.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019390.html
Conflicts:
.zuul.yaml
lower-constraints.txt
NOTE(hberaud): Conflicts are due to different base jobs in zuul and
different constraints in lower-constraints
Change-Id: Icf48ef72fbfff88dda2714b386dbbfe355dc1acb
(cherry picked from commit 686a8b6182)
(cherry picked from commit 1682ef69ae)
This change add a min value of 1 to
[oslo_messaging_rabbit]/rpc_conn_pool_size
such that there is always at least 1 connection avaiable.
This change add a runtime check to ensure that
[oslo_messaging_rabbit]/rpc_conn_pool_size is greater than
or equal too [oslo_messaging_rabbit]/conn_pool_min_size
Change-Id: I2ad4b9f1d012c9f0586a932ac27d96da1bcc4e4c
Closes-Bug: #1899533
(cherry picked from commit 00d15eaeab)
(cherry picked from commit 8f5847dcbe)
Previously, we have switched to use default exchanges
to avoid excessive amounts of exchange not found messages.
But it does not actually solve the problem because
reply_* queue is already gone and agent will not receive callbacks.
after some debugging, I found under some circumstances
seems rabbitmq consumer does not receive basic cancel
signal when queue is already gone. This might due to
rabbitmq try to restart consumer when queue is down
(for example when split brain). In such cases,
it might be better to fail early.
by reading the code, seems like x-cancel-on-ha-failover
is not dedicated to mirror queues only, https://github.com/rabbitmq/rabbitmq-server/blob/master/src/rabbit_channel.erl#L1894,
https://github.com/rabbitmq/rabbitmq-server/blob/master/src/rabbit_channel.erl#L1926.
By failing early, in my own test setup,
I could solve a certain case of exchange not found problem.
Change-Id: I2ae53340783e4044dab58035bc0992dc08145b53
Related-bug: #1789177
(cherry picked from commit 196fa877a9)
Occasionally I saw large number of connectionforced exceptions.
such exceptions cannot be healed automatically and requires a reboot.
catch it and ensure connection established.
Change-Id: I5c468d10230f05438df780e045f1e92662edf070
Closes-Bug: #1883038
(cherry picked from commit 26e8bb4cc9)
The 'kombu.connection.Connection.ensure_connection' method has changed
from calling 'retry_over_time' on 'self.connect' to calling it on
'self._connection_factory' [1], meaning our mocks are outdated. Address
this change.
[1] https://github.com/celery/kombu/pull/1193/commits/398aa5b8cd1fe1fc
Change-Id: Ibbcf21a57ab1e3f90c21901296e5c088b645127c
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Closes-Bug: #1885923
(cherry picked from commit afb035d971)
test-setup.sh is called after bindep is run in CI, and tox is not setup.
Simplify the script so that it only does what's needed - install
qdrouterd for Ubuntu from qpid/testing.
Install the other packages using bindep, add test to amqp1 profile.
Add amqp1 to bindep_profiles where needed for scenario tests, previously
test-setup.sh added it everywhere.
NOTE(elod.illes): skip annotation removed from test_impl_rabbit.py, as
kombu is constrained in ussuri with the version that does not need any
test to skip.
Change-Id: Ic3a9e2c873619670edfbf71022d593f3cb5f70f2
Related-Bug: #1885923
(cherry picked from commit 7e406c312a)
I believe when connection pool running out of available
resources, there will be all kinds of weird consequences
following. So let's print warning logs when we are going
to waiting indefinitely for the lock
Change-Id: I5ca930cada523bc77c644703a0f02b9160816231
Related-bug: #1871813
(cherry picked from commit 96300a3221)
Update the URL to the upper-constraints file to point to the redirect
rule on releases.openstack.org so that anyone working on this branch
will switch to the correct upper-constraints list automatically when
the requirements repository branches.
Until the requirements repository has as stable/ussuri branch, tests will
continue to use the upper-constraints list on master.
Change-Id: Icde5163e169fba2831a024f6f3b8c39fc35cf44d
The repo is Python 3 now, so update hacking to version 3.0 which
supports Python 3.
Update local hacking check for new flake8 version.
Blacklist:
W504 line break after binary operator
Fix:
E741 ambiguous variable name
E117 over-indented
E305 expected 2 blank lines after class or function definition, found 1
F841 local variable 'e' is assigned to but never used
W605 invalid escape sequence '\.'
Change-Id: I99d574ca6569f1f177d2c5ce1011f269f4343619
The blocking executor has been deprecated in Pike and marked for removal
in Rocky, but some user like Mistral asked us to wait before. We decided
to remove this executor for Train or next cycle, now we are in the
Ussuri and after some researchs on usage I think we can go ahead.
This patch drop the deprecation warnings, related unit tests and
set the server with the threading executor is the default executor.
Change-Id: If07bab61ee2b148658b88be98b12f8539f274efe
Closes-Bug: #1715141
This patchset introduces scenarios for the functional tests to unify the
setup and configuration of alternate messaging backends for RPC and
Notifications. The scenarios are defined to reduce redundancy in
the testing of backends and to demonstrate functional correctness
across driver combinations.
Current driver support:
rabbit - RPC, Notify
amqp - RPC
kafka - Notify
RPC Notify
--------- ----------
scenario01 rabbit rabbit
scenario02 rabbit kafka
scenario03 amqp rabbit
scenario04 amqp kafka
It is anticipated that additional scenarios will be defined as new
drivers are introduced and/or new messaging intermediarites are supported.
Note: The removal of python2 jobs are also included patch
Change-Id: I0f86416623a0b718516147f0660b4df2b74cf867
Such non-existing methods are used as health probes.
Please see bug for details.
Change-Id: I8f6b4a669ec11721f76cf03abcd7d802c3c11eb5
Closes-Bug: #1857319
Adding some debug logs to track execution on the AMQPListener poll
function to observe if workers incoming messages are dispatched to
workers and if listener is stuck.
Change-Id: Ia9b9ef62b0b59c78283c6a8cc5b7ce42282e73b5
Waiting on a threading.Event with eventlet can cause busy looping via
epoll_wait, see related bug for more details.
Change-Id: I007613058a2d21d1712c02fa6d1602b63705c1ab
Related-bug: #1518430
The telemetry tests are not actively maintained and have been failing
checks for quite some time. Remove the non-voting tests for now and
plan to introduce new tests in the future for better coverage of
notifications.
Change-Id: I6c30c28ee4c8be4677ccecf8822af15b060cf804
Sphinx 1.8 introduced [1] the '--keep-going' argument which, as its name
suggests, keeps the build running when it encounters non-fatal errors.
This is exceptionally useful in avoiding a continuous edit-build loop
when undertaking large doc reworks where multiple errors may be
introduced.
[1] https://github.com/sphinx-doc/sphinx/commit/e3483e9b045
Change-Id: If9885a1f064226909181d8b69241eb814deb2105
Typically a simple log will not narrow down the
performance, but give us more information about
the service status.
Change-Id: I51c8f2743dd39cccd3d1d021d3c50dc09f70cd97
Closes-Bug: #1847747
Elod Illes
OpenStack Release Bot