Open Stack

Hi everyone,

the largescale-sig currently recommends the following rabbitmq policy [1]: '^(?!(amq\.)|(.*_fanout_)|(reply_)).*'.

If I found the history of this setting correctly, it resulted from this mailinglist thread [2] which came to the conclusion:

> * use durable-queue and replication for long-running queues/exchanges
> * use non-durable-queue without replication for short (fanout, reply_) queues

However I am unsure if reply_ queues are actually shorted lived than the "long-running" ones.
If we take the example of the cinder-scheduler we have the following queues:

* cinder-scheduler: Tied to the lifetime of the whole cinder-scheduler cluster; currently durable + replicated
* cinder-scheduler.myhostname: Tied to the lifetime of the cinder-scheduler service, but not removed when the service stops; currently durable + replicated
* cinder-scheduler_fanout_somerandomid: Tied to the lifetime of the cinder-scheduler service, but removed when the service stops; currently neither durable nor replicated
* reply_somerandomid: Tied to the lifetime of the cinder-scheduler service, but removed when the service stops; currently neither durable nor replicated

If I read got all of the above correctly then reply_ and fanout queues are actually not shorter lived than the normal queue to send requests to that service.
The only difference is that we remove them when the service itself stops.

Therefor I want to propose the question if we should not also make these queues durable and replicated.

Thank you

[1]: https://docs.openstack.org/large-scale/other/rabbitmq.html#pattern
[2]: https://lists.openstack.org/pipermail/openstack-discuss/2020-August/016562.html

--
Felix Huettner

Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie hier<https://www.datenschutz.schwarz>.