Use stream queues instead of fanouts

[Arnaud Morin]

Rabbitmq introduced the stream queue type that can be used to replace the fanouts.

This bug is to follow-up the rabbitmq implementation for streams and other related features.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/oslo.messaging/+/890824
Committed: https://opendev.org/openstack/oslo.messaging/commit/3438726dd08eef03a0962c72096f268a54fd7f4e
Submitter: "Zuul (22348)"
Branch: master

commit 3438726dd08eef03a0962c72096f268a54fd7f4e
Author: Arnaud Morin <email address hidden>
Date: Wed Jul 26 10:34:19 2023 +0200

    Add some logs when sending RPC messages

    Related-bug: #2031497

    Signed-off-by: Arnaud Morin <email address hidden>
    Change-Id: I7d0c318624d3d02182392ca3f06eed04d4133728

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/oslo.messaging/+/889701
Committed: https://opendev.org/openstack/oslo.messaging/commit/f23f3276c4f8c156c7a917ffd05db6b3b010b807
Submitter: "Zuul (22348)"
Branch: master

commit f23f3276c4f8c156c7a917ffd05db6b3b010b807
Author: Arnaud Morin <email address hidden>
Date: Wed Jul 26 12:12:16 2023 +0200

    Allow creating transient queues with no expire

    When an operator rely on rabbitmq policies, there is no point to set the
    queue TTL in config.
    Moreover, using policies is much more simpler as you dont need to
    delete/recreate the queues to apply the new parameter (see [1]).
    So, adding the possibility to set the transient queue TTL to 0 will
    allow the creation of the queue without the x-expire parameter and only
    the policy will apply.

    [1] https://www.rabbitmq.com/parameters.html#policies

    Related-bug: #2031497

    Signed-off-by: Arnaud Morin <email address hidden>
    Change-Id: I34bad0f6d8ace475c48839adc68a023dd0c380de

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/oslo.messaging/+/889313
Committed: https://opendev.org/openstack/oslo.messaging/commit/8e3c523fd74257a78ceb384063f81db2e92a2ebd
Submitter: "Zuul (22348)"
Branch: master

commit 8e3c523fd74257a78ceb384063f81db2e92a2ebd
Author: Arnaud Morin <email address hidden>
Date: Fri Jul 21 16:51:51 2023 +0200

    Auto-delete the failed quorum rabbit queues

    When rabbit is failing for a specific quorum queue, the only thing to
    do is to delete the queue (as per rabbit doc, see [1]).

    So, to avoid the RPC service to be broken until an operator eventually
    do a manual fix on it, catch any INTERNAL ERROR (code 541) and trigger
    the deletion of the failed queues under those conditions.
    So on next queue declare (triggered from various retries), the queue
    will be created again and the service will recover by itself.

    Closes-Bug: #2028384
    Related-bug: #2031497

    [1] https://www.rabbitmq.com/quorum-queues.html#availability

    Signed-off-by: Arnaud Morin <email address hidden>
    Change-Id: Ib8dba833542973091a4e0bf23bb593aca89c5905

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/2023.2
Review: https://review.opendev.org/c/openstack/oslo.messaging/+/900891

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/oslo.messaging/+/900891
Committed: https://opendev.org/openstack/oslo.messaging/commit/34260a40358b17980f151dd6f4c4145533fba799
Submitter: "Zuul (22348)"
Branch: stable/2023.2

commit 34260a40358b17980f151dd6f4c4145533fba799
Author: Arnaud Morin <email address hidden>
Date: Fri Jul 21 16:51:51 2023 +0200

    Auto-delete the failed quorum rabbit queues

    When rabbit is failing for a specific quorum queue, the only thing to
    do is to delete the queue (as per rabbit doc, see [1]).

    So, to avoid the RPC service to be broken until an operator eventually
    do a manual fix on it, catch any INTERNAL ERROR (code 541) and trigger
    the deletion of the failed queues under those conditions.
    So on next queue declare (triggered from various retries), the queue
    will be created again and the service will recover by itself.

    Closes-Bug: #2028384
    Related-bug: #2031497

    [1] https://www.rabbitmq.com/quorum-queues.html#availability

    Signed-off-by: Arnaud Morin <email address hidden>
    Change-Id: Ib8dba833542973091a4e0bf23bb593aca89c5905
    (cherry picked from commit 8e3c523fd74257a78ceb384063f81db2e92a2ebd)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/oslo.messaging/+/888479
Committed: https://opendev.org/openstack/oslo.messaging/commit/989dbb8aad8be68a9c63e2e6a4d445cc445c051c
Submitter: "Zuul (22348)"
Branch: master

commit 989dbb8aad8be68a9c63e2e6a4d445cc445c051c
Author: Arnaud Morin <email address hidden>
Date: Thu Apr 13 17:53:18 2023 +0200

    Enable use of quorum queues for transient messages

    Add a new flag rabbit_transient_quorum_queue to enable the use of quorum
    for transient queues (reply_ and _fanout_)

    This is helping a lot OpenStack services to not fail (and recover) from
    a rabbit node issue.

    Related-bug: #2031497

    Signed-off-by: Arnaud Morin <email address hidden>
    Change-Id: Icee5ee6938ca7c9651f281fb835708fc88b8464f

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/oslo.messaging/+/889425
Committed: https://opendev.org/openstack/oslo.messaging/commit/4614132ad01d7e4559c4ff43c1e7dba1c1bdb81e
Submitter: "Zuul (22348)"
Branch: master

commit 4614132ad01d7e4559c4ff43c1e7dba1c1bdb81e
Author: Arnaud Morin <email address hidden>
Date: Mon Jul 24 21:48:20 2023 +0200

    Add QManager to amqp driver

    The purpose of this change is to introduce an optional mechanism to keep
    the queues name consistent between service restart.
    Oslo messaging is already re-using the queues while running, but the
    queues are created using a random name at the beginning.

    This change propose an option named use_queue_manager (default to False
    - so the behavior is not changed) that can be set to True to switch to a
    consistent naming based on hostname and processname.

    Related-bug: #2031497

    Signed-off-by: Arnaud Morin <email address hidden>
    Change-Id: I2acdef4e03164fdabcb50fb98a4ac14b1aefda00

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/2023.1
Review: https://review.opendev.org/c/openstack/oslo.messaging/+/905531

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/oslo.messaging/+/890825
Committed: https://opendev.org/openstack/oslo.messaging/commit/e95f334459d4dfd3778ec9e84d716f69f2c08ad5
Submitter: "Zuul (22348)"
Branch: master

commit e95f334459d4dfd3778ec9e84d716f69f2c08ad5
Author: julien.cosmao <email address hidden>
Date: Tue Jul 25 15:42:22 2023 +0200

    Add an option to use rabbitmq stream for fanout queues

    This is introducing the "stream" queues for fanout so all components
    relying on fanout can use the same stream, lowering the number of queues
    needed and leveraging the new "stream" type of queues from rabbitmq.

    Closes-Bug: #2031497

    Change-Id: I5056a19aada9143bcd80aaf064ced8cad441e6eb
    Signed-off-by: Arnaud Morin <email address hidden>

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/oslo.messaging/+/905531
Committed: https://opendev.org/openstack/oslo.messaging/commit/dcad86be5f7262f0f0323144dd47aea0b2dd1db2
Submitter: "Zuul (22348)"
Branch: stable/2023.1

commit dcad86be5f7262f0f0323144dd47aea0b2dd1db2
Author: Arnaud Morin <email address hidden>
Date: Fri Jul 21 16:51:51 2023 +0200

    Auto-delete the failed quorum rabbit queues

    When rabbit is failing for a specific quorum queue, the only thing to
    do is to delete the queue (as per rabbit doc, see [1]).

    So, to avoid the RPC service to be broken until an operator eventually
    do a manual fix on it, catch any INTERNAL ERROR (code 541) and trigger
    the deletion of the failed queues under those conditions.
    So on next queue declare (triggered from various retries), the queue
    will be created again and the service will recover by itself.

    Closes-Bug: #2028384
    Related-bug: #2031497

    [1] https://www.rabbitmq.com/quorum-queues.html#availability

    Signed-off-by: Arnaud Morin <email address hidden>
    Change-Id: Ib8dba833542973091a4e0bf23bb593aca89c5905
    (cherry picked from commit 8e3c523fd74257a78ceb384063f81db2e92a2ebd)

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/zed
Review: https://review.opendev.org/c/openstack/oslo.messaging/+/907267

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/oslo.messaging/+/908840

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/oslo.messaging 14.7.0 release.

[Christian Rohmann (christian-rohmann)]

Will oslo.message >= 14.7.0 and this feature still make it into the Caracal release?
According to https://releases.openstack.org/caracal/schedule.html the Oslo feature freeze was "Feb 12 - Feb 16" ?

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/oslo.messaging/+/908840
Committed: https://opendev.org/openstack/oslo.messaging/commit/5988c7bf141ecbf319236dffc2c0ab32c3f7393e
Submitter: "Zuul (22348)"
Branch: master

commit 5988c7bf141ecbf319236dffc2c0ab32c3f7393e
Author: Guillaume Espanel <email address hidden>
Date: Wed Jan 24 12:11:56 2024 +0100

    Restore read stream queues from last known offset

    When an agent reconnected to a rabbitmq server, it would start
    consumming messages from the last offset available in the stream.

    This could cause important messages to be lost.

    With this patch, oslo_messaging will keep track of the last consummed
    offset and restore reading from that point.

    Related-bug: #2031497

    Change-Id: I449008829b0c0a1a759c211b83f7a99d9c7f2c0d

[OpenStack Infra (hudson-openstack)]

Change abandoned by "Elod Illes <email address hidden>" on branch: stable/zed
Review: https://review.opendev.org/c/openstack/oslo.messaging/+/907267
Reason: stable/zed branch of openstack/oslo.messaging is about to be deleted. To be able to do that, all open patches need to be abandoned. Please cherry pick the patch to unmaintained/zed if you want to further work on this patch.