[nova][neutron][oslo][ops][kolla] rabbit bindings issue
Satish Patel
satish.txt at gmail.com
Fri Aug 14 14:59:28 UTC 2020
Fabian,
what do you mean?
>> I think vexxhost is running (1) with their openstack-operator - for reasons.
On Fri, Aug 14, 2020 at 7:28 AM Fabian Zimmermann <dev.faz at gmail.com> wrote:
>
> Hello again,
>
> just a short update about the results of my tests.
>
> I currently see 2 ways of running openstack+rabbitmq
>
> 1. without durable-queues and without replication - just one rabbitmq-process which gets (somehow) restarted if it fails.
> 2. durable-queues and replication
>
> Any other combination of these settings leads to more or less issues with
>
> * broken / non working bindings
> * broken queues
>
> I think vexxhost is running (1) with their openstack-operator - for reasons.
>
> I added [kolla], because kolla-ansible is installing rabbitmq with replication but without durable-queues.
>
> May someone point me to the best way to document these findings to some official doc?
> I think a lot of installations out there will run into issues if - under load - a node fails.
>
> Fabian
>
>
> Am Do., 13. Aug. 2020 um 15:13 Uhr schrieb Fabian Zimmermann <dev.faz at gmail.com>:
>>
>> Hi,
>>
>> just did some short tests today in our test-environment (without durable queues and without replication):
>>
>> * started a rally task to generate some load
>> * kill-9-ed rabbitmq on one node
>> * rally task immediately stopped and the cloud (mostly) stopped working
>>
>> after some debugging i found (again) exchanges which had bindings to queues, but these bindings didnt forward any msgs.
>> Wrote a small script to detect these broken bindings and will now check if this is "reproducible"
>>
>> then I will try "durable queues" and "durable queues with replication" to see if this helps. Even if I would expect
>> rabbitmq should be able to handle this without these "hidden broken bindings"
>>
>> This just FYI.
>>
>> Fabian
More information about the openstack-discuss
mailing list