We are thrilled to announce the release of: oslo.messaging 14.7.0: Oslo Messaging API This release is part of the caracal release series. The source is available from: https://opendev.org/openstack/oslo.messaging Download the package from: https://pypi.org/project/oslo.messaging Please report issues through: https://bugs.launchpad.net/oslo.messaging/+bugs For more details, please see below. 14.7.0 ^^^^^^ New Features * Add three new options ("use_queue_manager", "hostname", "processname") to switch oslo.messaging from random queue names (for reply_q and fanouts) to consistent naming. The default value is False, so oslo.messaging will still use random queue names if nothing is set in configuration file of services. When switching use_queue_manager to True, the uuid4 random string from the queue name is replaced with a combination of hostname, processname and counter. The counter will be kept in shared memory (/dev/shm/x_y_qmanager). This way, when a service using oslo.messaging restarts (e.g. neutron), it will re-create the queues using the same name as the previous run, so no new queues are created and no need for rabbitmq to delete the previous queues. This is extremely useful for operator to debug which queue belong to which server/process. It's also higlhy recommended to enable this feature when using quorum queues for transient (option named "rabbit_transient_quorum_queue") to avoid consuming all erlang atoms after some time. * Add an option to enable transient queues to use quorum. Transient queues in OpenStack are not so transient, they live the whole process lifetime (e.g. until you restart a service, like nova- compute). Transient here means they belong to a specific process, compared to regular queues which may be used by more processes. Usually, transients queues are the "fanout" and "reply" queues. By default, without any rabbitmq policy tuning, they are not durable neither highly available. By enabling quorum for transients, oslo.messaging will declare quorum queues instead of classic on rabbitmq. As a result, those queues will automatically become HA and durable. Note that this may have an impact on your cluster, as rabbit will need more cpu, ram and network bandwith to manage the queues. This was tested at pretty large scale (2k hypervisors) with a cluster of 5 nodes. Also note that the current rabbitmq implementation rely on a fixed number of "erlang atom" (5M by default), and one atom is consumed each time a quorum queue is created with a different name. If your deployment is doing a lot of queue deletion/creation, you may consume all your atoms quicker. When enabling quorum for transients, you may also want to update your rabbitmq policies accordingly (e.g. make sure they apply on quorum). This option will stay disabled by default for now but may become the default in the future. * The name of the "reply_q" is now logged when a timeout occurs while waiting for a reply. * Add an option to use stream queues for rabbitmq driver instead of fanouts. Changes in oslo.messaging 14.6.0..14.7.0 ---------------------------------------- 795185d4 Display coverage report 94a3ebcb reno: Update master for unmaintained/yoga 97d457f0 Display the reply queue's name in timeout logs 4f4c2772 Bump hacking (again) 22634362 Bump hacking a196e775 Remove scenario 03/04 tests from CI c9202b01 Drop unused function from scenario test script 800c5882 Utilize the new RequestContext redacted_copy method 6e7a5725 cleanup amqp1 scenarios remnants setups e95f3344 Add an option to use rabbitmq stream for fanout queues df0e4acd Update the python search path for extra qdrouter modules ee5b3517 Update python classifier in setup.cfg 4614132a Add QManager to amqp driver 989dbb8a Enable use of quorum queues for transient messages 03dcc3c7 Bump bandit Diffstat (except docs and test files) ------------------------------------- .pre-commit-config.yaml | 2 +- .zuul.yaml | 18 -- oslo_messaging/_drivers/amqpdriver.py | 111 ++++++++++++- oslo_messaging/_drivers/impl_rabbit.py | 143 ++++++++++++---- oslo_messaging/hacking/checks.py | 6 +- oslo_messaging/notify/logger.py | 2 +- oslo_messaging/notify/notifier.py | 57 ++----- .../rabbit_queue_manager-363209285cbbe257.yaml | 21 +++ .../rabbit_transient_quorum-fc3c3f88ead90034.yaml | 31 ++++ .../notes/reply_q-timeout-e3c3bae636e8bc74.yaml | 4 + releasenotes/notes/stream-c3dd31ee98f6bbd7.yaml | 4 + releasenotes/source/yoga.rst | 2 +- requirements.txt | 5 +- setup.cfg | 2 + test-requirements.txt | 6 +- tools/setup-scenario-env.sh | 16 -- tox.ini | 24 +-- 23 files changed, 400 insertions(+), 376 deletions(-) Requirements updates -------------------- diff --git a/requirements.txt b/requirements.txt index e0271884..dee5ed99 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,4 +0,0 @@ -# The order of packages is significant, because pip processes them in the order -# of appearance. Changing the order has an impact on the overall integration -# process, which may cause wedges in the gate later. - @@ -8,0 +5 @@ oslo.config>=5.2.0 # Apache-2.0 +oslo.context>=5.3.0 # Apache-2.0 diff --git a/test-requirements.txt b/test-requirements.txt index daf74261..2b4fd0c2 100644 --- a/test-requirements.txt +++ b/test-requirements.txt @@ -1,4 +0,0 @@ -# The order of packages is significant, because pip processes them in the order -# of appearance. Changing the order has an impact on the overall integration -# process, which may cause wedges in the gate later. - @@ -6 +2 @@ -hacking>=3.0.1,<=4.1.0 # Apache-2.0 +hacking>=6.1.0,<=6.2.0 # Apache-2.0