<div dir="ltr">Cool thanks for the summary. You seem to have this under control so I might bravely run away. I definitely think these are issues that deserve a backport when the time comes.<div><br></div><div>Michael</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 5, 2019 at 1:52 PM Harald Jensås <<a href="mailto:hjensas@redhat.com">hjensas@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 2019-02-05 at 09:54 +1100, Michael Still wrote:<br>
> Hi,<br>
> <br>
> I’ve been chasing a bug in ironic’s neutron agent for the last few<br>
> days and I think its time to ask for some advice.<br>
> <br>
<br>
I'm working on the same issue. (In fact there are two issues.)<br>
<br>
> Specifically, I was asked to debug why a set of controllers was using<br>
> so much RAM, and the answer was that rabbitmq had a queue called<br>
> <a href="http://ironic-neutron-agent-heartbeat.info" rel="noreferrer" target="_blank">ironic-neutron-agent-heartbeat.info</a> with 800,000 messages enqueued.<br>
> This notification queue is used by ironic’s neutron agent to<br>
> calculate the hash ring. I have been able to duplicate this issue in<br>
> a stock kolla-ansible install with ironic turned on but no bare metal<br>
> nodes enrolled in ironic. About 0.6 messages are queued per second.<br>
> <br>
> I added some debugging code (hence the thread yesterday about<br>
> mangling the code kolla deploys), and I can see that the messages in<br>
> the queue are being read by the ironic neutron agent and acked<br>
> correctly. However, they are not removed from the queue.<br>
> <br>
> You can see your queue size while using kolla with this command:<br>
> <br>
> docker exec rabbitmq rabbitmqctl list_queues messages name<br>
> messages_ready consumers  | sort -n | tail -1<br>
> <br>
> My stock install that’s been running for about 12 hours currently has<br>
> 8,244 messages in that queue.<br>
> <br>
> Where I’m a bit stumped is I had assumed that the messages weren’t<br>
> being acked correctly, which is not the case. Is there something<br>
> obvious about notification queues like them being persistent that<br>
> I’ve missed in my general ignorance of the underlying implementation<br>
> of notifications?<br>
> <br>
<br>
I opened a oslo.messaging bug[1] yesterday. When using notifications<br>
and all consumers use one or more pools. The ironic-neutron-agent does<br>
use pools for all listeners in it's hash-ring member manager. And the<br>
result is that notifications are published to the 'ironic-neutron-<br>
<a href="http://agent-heartbeat.info" rel="noreferrer" target="_blank">agent-heartbeat.info</a>' queue and they are never consumed.<br>
<br>
The second issue, each instance of the agent uses it's own pool to<br>
ensure all agents are notified about the existance of peer-agents. The<br>
pools use a uuid that is generated at startup (and re-generated on<br>
restart, stop/start etc). In the case where<br>
`[oslo_messaging_rabbit]/amqp_auto_delete = false` in neutron config<br>
these uuid queues are not automatically removed. So after a restart of<br>
the ironic-neutron-agent the queue with the old UUID is left in the<br>
message broker without no consumers, growing ...<br>
<br>
<br>
I intend to push patches to fix both issues. As a workaround (or the<br>
permanent solution) will create another listener consuming the<br>
notifications without a pool. This should fix the first issue.<br>
<br>
Second change will set amqp_auto_delete for these specific queues to<br>
'true' no matter. What I'm currently stuck on here is that I need to<br>
change the control_exchange for the transport. According to<br>
oslo.messaging documentation it should be possible to override the<br>
control_exchange in the transport_url[3]. The idea is to set<br>
amqp_auto_delete and a ironic-neutron-agent specific exchange on the<br>
url when setting up the transport for notifications, but so far I<br>
belive the doc string on the control_exchange option is wrong.<br>
<br>
<br>
NOTE: The second issue can be worked around by stopping and starting<br>
rabbitmq as a dependency of the ironic-neutron-agent service. This<br>
ensure only queues for active agent uuid's are present, and those<br>
queues will be consumed.<br>
<br>
<br>
--<br>
Harald Jensås<br>
<br>
<br>
[1] <a href="https://bugs.launchpad.net/oslo.messaging/+bug/1814544" rel="noreferrer" target="_blank">https://bugs.launchpad.net/oslo.messaging/+bug/1814544</a><br>
[2] <a href="https://storyboard.openstack.org/#!/story/2004933" rel="noreferrer" target="_blank">https://storyboard.openstack.org/#!/story/2004933</a><br>
[3] <br>
<a href="https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/transport.py#L58-L62" rel="noreferrer" target="_blank">https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/transport.py#L58-L62</a><br>
<br>
</blockquote></div>