Description of problem: By default in Havana, the qpid queues are not set to auto delete. This causes issues when timeouts occur and new queues are created. Version-Release number of selected component (if applicable): How reproducible: Everytime Steps to Reproduce: 1. Start a compute node 2. use `qpid-stat -q` to examine queue properties (qpid-stat is in the qpid-tools package) 3. Actual results: queue are not set to auto delete Expected results: Additional info: easiest to change in /usr/lib/python2.6/site-packages/neutron/openstack/common/rpc/impl_qpid.py See upstream BZ https://bugs.launchpad.net/oslo.messaging/+bug/1318742
Simple change, greatly improves performance, scalability and reliability of system under load
As a workaround, we may set amqp_auto_delete = True in neutron-dist.conf until the fix is propagated to our RPC layer code.
We do not depend on oslo.messaging team since we have a workaround that can be applied thru neutron-dist.conf
I've talked to sileht@ from oslo.messaging cores, and he told me that forcing amqp_auto_delete like that will result in that being set for TopicConsumers too. That will mean that if consumer is dead for a short time, the queue will be dropped. This may result in notifications lost, and other nasty things. Quoting: [15:04] <sileht> ihrachyshka, I think you can loose notifications if nobody consume them, and imagines you restart a nova-compute just when the scheduler ask something to the compute, you will lost the calls, and the caller (scheduler will retry until the compute is back) instead of having the scheduler waiting and the nova-compute restarting where it was stopped [15:07] <sileht> ihrachyshka, on small deployement that doesn't consume notification, I think it's doable, but I big one you will create many unuseful message each time you restart something [15:08] <sileht> ihrachyshka, for the notification part the rabbit driver have a workaround, that the qpid don't have So we still need a solution for this from oslo.messaging team. :|
Moving to A6 as per Livnat's request. The reasoning is that the bug is internal and is not something any known customer is waiting for.
Waiting for oslo.messaging guys to handle the issue in oslo in upstream first.