oslo.messaging 14.0.0 release

meta:version: 14.0.0
meta:diff-start: -
meta:series: zed
meta:release-type: release
meta:pypi: yes
meta:first: no
meta:release:Author: Elod Illes <elod.illes@est.tech>
meta:release:Commit: Elod Illes <elod.illes@est.tech>
meta:release:Change-Id: I5756f9bbef9a8b728794bfdd44299579c07dce3f
meta:release:Code-Review+1: Daniel Bengtsson <dbengt@redhat.com>
meta:release:Code-Review+2: Elod Illes <elod.illes@est.tech>
meta:release:Code-Review+2: Thierry Carrez <thierry@openstack.org>
meta:release:Workflow+1: Thierry Carrez <thierry@openstack.org>

As was reported in the related bug some time ago, setting that
option to True for nova-compute can break it as it's non-wsgi service.
We also noticed same problems with randomly stucked non-wsgi services
like e.g. neutron agents and probably the same issue can happen with
any other non-wsgi service.

To avoid that this patch changes default value of that config option
to be False.
Together with [1] it effectively reverts change done in [2] some time
ago.

[1] https://review.opendev.org/c/openstack/oslo.messaging/+/800621
[2] https://review.opendev.org/c/openstack/oslo.messaging/+/747395

Related-Bug: #1934937
Closes-Bug: #1961402

Change-Id: I85f5b9d1b5d15ad61a9fcd6e25925b7eeb8bf6e7

In Zed cycle testing runtime, we are targetting to drop the
python 3.6/3.7 support, project started adding python 3.8 as minimum,

example nova:
- https://github.com/openstack/nova/blob/56b5aed08c6a3ed81b78dc216f0165ebfe3c3350/setup.cfg#L13

Change-Id: Id23d3845db716d26175d71280dbedf93736d19de

As explained in the link below kombu has login method called external
https://docs.celeryq.dev/projects/kombu/en/latest/_modules/kombu/connection.html

The login method external is not listed as a choice in the Rabbit driver

As explained in RabbitMQ documention
https://www.rabbitmq.com/access-control.html
for Authentication using Client TLS (x.509) Certificate Data
clients must be configured to use the EXTERNAL mechanism.

Closes-Bug: #1970276
Change-Id: I5c38d3a3cafd49f8abc031e36bc595f32a8631d2

the quorum queue type add features that did not exist before or not
handled in rabbitmq the following link shows some of them
https://blog.rabbitmq.com/posts/2020/04/rabbitmq-gets-an-ha-upgrade/

the options below control the quorum queue and ensure the stability of
the quorum system
x-max-in-memory-length
x-max-in-memory-bytes
x-delivery-limit

which control the memory usage and handle message poisoning

Closes-Bug: #1962348
Change-Id: I570227d6102681f4f9d8813ed0d7693a1160c21d

kombu 5.2.4 fixed an off-by-one issue that meant we were attempting
retries more than once [1]. We need to handle this to unblock the gate.
This was discovered by examining the call stack and comparing this with
recent changes in openstack/requirements.

[1] https://github.com/celery/kombu/commit/5bed2a8f983a3bf61c12443e7704ffd89991ef9a



Change-Id: I476e3c573523d5991c56b31ad4df1172196aa7f1
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>

    - test_ensure_four_retry
    - test_ensure_no_retry
    - test_ensure_one_retry

This is an automatically generated patch to ensure unit testing
is in place for all the of the tested runtimes for zed.

See also the PTI in governance [1].

[1]: https://governance.openstack.org/tc/reference/project-testing-interface.html

Change-Id: I73a0700baa1c9edfb7a4b82be94df8bacff3c226

Add file to the reno documentation build to show release notes for
stable/yoga.

Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/yoga.

Sem-Ver: feature
Change-Id: I3d2b041769c5c14a7d391c223dc499218a937e76

oslo.messaging 12.13.0 release

meta:version: 12.13.0
meta:diff-start: -
meta:series: yoga
meta:release-type: release
meta:pypi: yes
meta:first: no
meta:release:Author: Daniel Bengtsson <dbengt@redhat.com>
meta:release:Commit: Daniel Bengtsson <dbengt@redhat.com>
meta:release:Change-Id: I9a71c586c7ecb81363541f24550b6e276b52cf61
meta:release:Code-Review+2: Hervé Beraud <herveberaud.pro@gmail.com>
meta:release:Code-Review+2: Elod Illes <elod.illes@est.tech>
meta:release:Workflow+1: Elod Illes <elod.illes@est.tech>

oslo.messaging 12.12.0 release

meta:version: 12.12.0
meta:diff-start: -
meta:series: yoga
meta:release-type: release
meta:pypi: yes
meta:first: no
meta:release:Author: Hervé Beraud <hberaud@redhat.com>
meta:release:Commit: Hervé Beraud <hberaud@redhat.com>
meta:release:Change-Id: I27c955b47fafcb9db3be70d2a8f508fe9def348b
meta:release:Code-Review+2: Elod Illes <elod.illes@est.tech>
meta:release:Code-Review+1: Daniel Bengtsson <dbengt@redhat.com>
meta:release:Workflow+1: Elod Illes <elod.illes@est.tech>

https://www.rabbitmq.com/quorum-queues.html

The quorum queue is a modern queue type for RabbitMQ implementing a
durable, replicated FIFO queue based on the Raft consensus algorithm. It
is available as of RabbitMQ 3.8.0.

the quorum queues can not be set by policy so this should be done when
declaring the queue.

To declare a quorum queue set the x-queue-type queue argument to quorum
(the default is classic). This argument must be provided by a client at
queue declaration time; it cannot be set or changed using a policy. This
is because policy definition or applicable policy can be changed
dynamically but queue type cannot. It must be specified at the time of
declaration.

its good for the oslo messaging to add support for that type of queue
that have multiple advantaged over mirroring.

If quorum queues are sets mirrored queues will be ignored.

Closes-Bug: #1942933
Change-Id: Id573e04c287e034e50626daf6e18a34735d45251

The rabbit backend now applies the [oslo_messaging_notifications]retry,
[oslo_messaging_rabbit]rabbit_retry_interval, rabbit_retry_backoff and
rabbit_interval_max configuration parameters when tries to establish the
connection to the message bus during notification sending.

This patch also clarifies the differences between the behavior
of the kafka and the rabbit drivers in this regard.

Closes-Bug: #1917645
Change-Id: Id4ccafc95314c86ae918336e42cca64a6acd4d94

Yoga testing runtime[1] has been updated to add py39
testing as voting. Unit tests update are handled by the
job template change in openstack-zuul-job

- https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/820286

this commit updates the classifier in setup.cfg file.

[1] https://governance.openstack.org/tc/reference/runtimes/yoga.html

Change-Id: I26743858a0ca7a6e46bda821c8f29b6dff34ea15

The [oslo_messaging_notification]retry parameter is not applied during
connecting to the message bus. But the documentation implies it should[1][2].
The two possible drivers, rabbit and kafka, behaves differently.

1) The rabbit driver will retry the connection forever, blocking the caller
   process.

2) The kafka driver also ignores the retry configuration but the
   notifier call returns immediately even if the notification is not
   (cannot) be delivered.

This patch adds test cases to show the wrong behavior.

[1] https://docs.openstack.org/oslo.messaging/latest/configuration/opts.html#oslo_messaging_notifications.retry
[2] https://github.com/openstack/oslo.messaging/blob/feb72de7b81e3919dedc697f9fb5484a92f85ad8/oslo_messaging/notify/messaging.py#L31-L36

Related-Bug: #1917645

Change-Id: Id8557050157aecd3abd75c9114d3fcaecdfc5dc9

Currently this is how reconnect works:

- pyngus detects failure and invokes callback
  Controller.connection_failed() which in turn calls
  Controller._handle_connection_loss()

- The first thing that _handle_connection_loss does is to set
  self.addresser to None (important later)

- Then it defers _do_reconnect after a delay (normally 1 second)

- (1 second passes)

- _do_reconnect calls _hard_reset which resets the controller state

However, there is a race here.  This can happen:

- The above, up until it defers and waits for 1 second

- Controller.send() is invoked on a task

- A new Sender is created, and critically because self.reply_link
  still exists and is active, we call sender.attach and pass in
  self.addresser.  Remember _handle_connection_loss sets
  self.addresser to None.

- Eventually Sender.attach throws an AttributeError because it
  attempts to call addresser.resolve() but addresser is None

The reason this happens is because although the connection is dead,
the controller state is still half-alive because _hard_reset hasn't
been called yet since it's deferred one second in _do_reconnect.

The fix here is to move _hard_reset out of _do_reconnect and directly
into _handle_connection_loss.  The eventloop is woken up immediately
to process _hard_reset but _do_reconnect is still deferred as before
so as to retain the desired reconnect backoff behavior.

Closes-Bug: #1941652
Change-Id: Ife62a7d76022908f0dc6a77f1ad607cb2fbd3e8f

This option ``ssl_enforce_fips_mode`` allow us to enforce the FIPS mode
if supported by the version of python in use.

https://en.wikipedia.org/wiki/Federal_Information_Processing_Standards

Change-Id: I50c7de71bfd38137eb83d23e910298946507ce9f

In some circumstances services can be executed outside of mod_wsgi and
in a monkey patched environment. In this context we need to leave the
possibility to users to execute the heartbeat in a green thread.

The heartbeat_in_pthread was tagged as depreacted few months and planned
for a future removal. These changes drop this deprecation to allow to
enable green threads if needed.

Closes-Bug: #1934937
Change-Id: Iee2e5a6f7d71acba70bbc857f0bd7d83e32a7b8c

The amqp1 driver also needs this same logic, so split it out and share
it.

Change-Id: I2e9dbfa27887e26807f199c9d359bacd7c15c67a

This is an automatically generated patch to ensure unit testing
is in place for all the of the tested runtimes for yoga.

See also the PTI in governance [1].

[1]: https://governance.openstack.org/tc/reference/project-testing-interface.html

Change-Id: I0088ff54c4807f240a1db2457aeefcdf8b91375d

Add file to the reno documentation build to show release notes for
stable/xena.

Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/xena.

Sem-Ver: feature
Change-Id: Ia40ac2ccee4fe230605f3183b0b432b0e31bff04

Return back the message id cache feature to RPC listener, it was
removed while refactoring in I708c3d6676b974d8daac6817c15f596cdf35817b
See attached bug for more info.

We should not raise DuplicateMessageError to avoid rejecting the
previously ACK'ed message.

Closes-Bug: #1935883
Change-Id: Ie237e9e3fdc3fc27b3deb18b94751cdc3afd190e