Setuptools v54.1.0 introduces a warning that the use of dash-separated
options in 'setup.cfg' will not be supported in a future version [1].
Get ahead of the issue by replacing the dashes with underscores. Without
this, we see 'UserWarning' messages like the following on new enough
versions of setuptools:
UserWarning: Usage of dash-separated 'description-file' will not be
supported in future versions. Please use the underscore name
'description_file' instead
[1] https://github.com/pypa/setuptools/commit/a2e9ae4cb
Change-Id: I6e015bf3955e3ff7aa21bc86d3f6f69e0017ca29
Oslo.utils's fnmatch module was added to fix the py2.7 fnmatch module
who was not thread safe [1]. Python 2.7 is no longer supported so now we
can use the stdlib's fnmatch module and deprecate the one of oslo.utils.
[1] https://bugs.python.org/issue23191$
Change-Id: Id5381a0a5216783f0df594b126786947db16a8d1
Add file to the reno documentation build to show release notes for
stable/wallaby.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/wallaby.
Sem-Ver: feature
Change-Id: I2deb189cfdd7420e69060cd89c45b03b43c211af
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
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
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.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019390.html
Change-Id: Icf48ef72fbfff88dda2714b386dbbfe355dc1acb
The Threading method isAlive was deprecated a long time ago, in the favor
of is_alive(). Though in Python 3.9, isAlive is removed. We must switch
to it. Note that is_alive() is available at least in Python 3.5 (I tried)
and probably even earlier, so switching to is_alive() is not a problem
for the Python interpreter versions currently supported by OpenStack.
Change-Id: I9d671abcd2cea9c0c726edaddcd65e1093d96731
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
Introduced changes:
- pre-commit config and rules
- Add pre-commit to pep8 gate, Flake8 is covered in the pre-commit hooks.
- Applying fixes for pre-commit compliance in all code.
Also commit hash will be used instead of version tags in pre-commit to
prevend arbitrary code from running in developer's machines.
pre-commit will be used to:
- trailing whitespace;
- Replaces or checks mixed line ending (mixed-line-ending);
- Forbid files which have a UTF-8 byte-order marker (check-byte-order-marker);
- Checks that non-binary executables have a proper
shebang (check-executables-have-shebangs);
- Check for files that contain merge conflict strings (check-merge-conflict);
- Check for debugger imports and py37+ breakpoint()
calls in python source (debug-statements);
- Attempts to load all yaml files to verify syntax (check-yaml);
- Run flake8 checks (flake8) (local)
For further details about tests please refer to:
https://github.com/pre-commit/pre-commit-hooks
Change-Id: Ibd0c3d64fdc5c293d9d676d33eab828d9fde971f
Co-authored-by: Moisés Guimarães de Medeiros <moguimar@redhat.com>
Add file to the reno documentation build to show release notes for
stable/victoria.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/victoria.
Change-Id: I0e5758da8c95474b1ddda5419f80ae94da71d147
Sem-Ver: feature
Removing the experimental nature of this feature and activating it by default.
Now to run heartbeat in a green thread users should set this option to False.
Also deprecating this option to prepare future removal and force to always run
heartbeat in a python thread whatever the context.
Change-Id: I32a6c4ad0a456282ec02b5e4c8309489b3c17553
The purpose of this patch is to add an endpoint directly in RPC
dispatcher, so this endpoint will always be available, in a cross
project manner, without the need for projects to manage it by themself.
This endpoint stay disabled by default, so this change is harmless
without a specific configuration option.
To enable this ping endpoint, an operator will just have to add a new
parameter in the [DEFAULT] section, alongside with rpc_response_timeout
[DEFAULT]
rpc_ping_enabled=true # default is false
The purpose of this new endpoint is to help operators do a RPC call (a
ping) toward a specific RPC callback (e.g. a nova-compute, or a
neutron-agent).
This is helping a lot for monitoring agents (for example, if agents are
deployed in a kubernetes pod).
The endpoint is named oslo_rpc_server_ping.
Change-Id: I51cf67e060f240e6eb82260e70a057fe599f9063
Signed-off-by: Arnaud Morin <arnaud.morin@corp.ovh.com>
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
This patch bumps bandit allowed version to >=1.6.0,<1.7.0 in order to
avoid the errors detailed here https://github.com/PyCQA/bandit/pull/393
Change-Id: I9235560667f664643007b8ca0be1707eab4126ad
Signed-off-by: Moisés Guimarães de Medeiros <moguimar@redhat.com>
