- 24 Mar, 2022 3 commits
-
-
Thomas Goirand authored
- test_ensure_four_retry - test_ensure_no_retry - test_ensure_one_retry -
Thomas Goirand authored
-
Thomas Goirand authored
-
- 21 Feb, 2022 4 commits
-
-
Thomas Goirand authored
-
Thomas Goirand authored
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>
-
Thomas Goirand authored
-
Thomas Goirand authored
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>
-
- 08 Feb, 2022 1 commit
-
-
Zuul authored
-
- 05 Feb, 2022 1 commit
-
-
Hervé Beraud authored
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
-
- 12 Jan, 2022 2 commits
-
-
Zuul authored
-
Balazs Gibizer authored
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
-
- 21 Dec, 2021 2 commits
-
-
Zuul authored
-
dengzhaosen authored
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
-
- 24 Nov, 2021 1 commit
-
-
Balazs Gibizer authored
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
-
- 09 Nov, 2021 1 commit
-
-
John Eckersberg authored
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
-
- 21 Oct, 2021 1 commit
-
-
Zuul authored
-
- 14 Oct, 2021 1 commit
-
-
Hervé Beraud authored
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
-
- 29 Sep, 2021 1 commit
-
-
Thomas Goirand authored
-
- 22 Sep, 2021 1 commit
-
-
John Eckersberg authored
The amqp1 driver also needs this same logic, so split it out and share it. Change-Id: I2e9dbfa27887e26807f199c9d359bacd7c15c67a
-
- 13 Sep, 2021 2 commits
- 10 Sep, 2021 3 commits
-
-
OpenStack Release Bot authored
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
-
OpenStack Release Bot authored
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
-
Nikita Kalyanov authored
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
-
- 27 Aug, 2021 3 commits
-
-
Thomas Goirand authored
-
Thomas Goirand authored
-
Thomas Goirand authored
oslo.messaging 12.9.1 release meta:version: 12.9.1 meta:diff-start: - meta:series: xena 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: Ic4256e444489b060b31fa5b7f3542a8044ed6958 meta:release:Code-Review+2: Thierry Carrez <thierry@openstack.org> meta:release:Code-Review+2: Elod Illes <elod.illes@est.tech> meta:release:Workflow+1: Elod Illes <elod.illes@est.tech>
-
- 23 Aug, 2021 2 commits
-
-
Thomas Goirand authored
-
Thomas Goirand authored
oslo.messaging 12.8.0 release meta:version: 12.8.0 meta:diff-start: - meta:series: xena meta:release-type: release meta:pypi: yes meta:first: yes meta:release:Author: Hervé Beraud <hberaud@redhat.com> meta:release:Commit: Hervé Beraud <hberaud@redhat.com> meta:release:Change-Id: I6389de7eb3be8778839ecb300b07d5b80d9551cb meta:release:Code-Review+2: Thierry Carrez <thierry@openstack.org> meta:release:Code-Review+2: Elod Illes <elod.illes@est.tech> meta:release:Workflow+1: Elod Illes <elod.illes@est.tech>
-
- 16 Aug, 2021 1 commit
-
-
Thomas Goirand authored
-
- 10 Aug, 2021 4 commits
-
-
John Eckersberg authored
Each _SocketConnection object is unique per-peer. For example, the properties attribute may contain keys such as 'x-ssl-peer-name'. Reusing the existing _socket_connection during failover will cause the TLS handshake to fail since the peer name will not match. There is potential for other similar-yet-unexplored bad things to happen as well. Instead, reconnect by waking up the eventloop via the _do_reconnect method, which reconstructs the connection properties to reflect the new (failed-over-to) host and ultimately crates a new _SocketConnection (or re-uses a *valid* old one) in eventloop.Thread.connect(). Closes-Bug: #1938945 Change-Id: I0c8dc447f4dc8d0d08c312a1f3e6fa1745fb69fd
-
John Eckersberg authored
This breaks out the generation of brokers and transport_url into separate methods. These methods are used in the next patch in this series, where TestSSL is updated to inherit from TestFailover, and TestSSL overrides the _gen_brokers and _gen_transport_url methods to supply the necessary SSL-aware options. Change-Id: Ia2f977795abc2e81a996e299867e05d41057f33f
-
John Eckersberg authored
This reverts commit 8f5cfda6. Reason for revert: This was supposed to be temporary to unblock the gate. Whatever broke SSL cert generation in the first place appears to be fixed because I can run SSL tests now. Change-Id: I4f286cf3af0d578f472b84fe355c812910c7a121
-
Zuul authored
-
- 12 Jul, 2021 1 commit
-
-
Nikita Kalyanov authored
We should properly limit the maximum timeout with a 'min' to avoid long delays before message processing. Such delays may happen if the connection to a RabbitMQ server is re-established at the same time when the message arrives (see attached bug for more info). Moreover, this change is in line with the original intent to actually have an upper limit on maximum possible timeout (see comments in code and in the original review). Closes-Bug: #1935864 Change-Id: Iebc8a96e868d938a5d250bf9d66d20746c63d3d5
-
- 25 Jun, 2021 1 commit
-
-
Zuul authored
-
- 10 Jun, 2021 1 commit
-
-
Zuul authored
-
- 08 Jun, 2021 1 commit
-
-
Ching Kuo authored
This commit added support to send rpc metrics to oslo.metrics. Changes includes: - Adding client wrapper for oslo.metrics to process metrics information and send to oslo.metrics socket - Modify rpc client to send metric when certain rpc events happens For more information on oslo.metrics https://opendev.org/openstack/oslo.metrics Change-Id: Idf8cc0e52ced1f697ac4048655eff4c956fd5c79
-
- 07 Jun, 2021 1 commit
-
-
yangyawei authored
The patch bumps min version of tox to 3.18.0 in order to replace tox's whitelist_externals by allowlist_externals option: https://github.com/tox-dev/tox/blob/master/docs/changelog.rst#v3180-2020-07-23 Change-Id: If129b56be47952d018b9f6024d2a192950c1a974
-
- 26 May, 2021 1 commit
-
-
Zuul authored
-