Hi again, If I understand correctly neutron code, we have security group rule update notified twice: First with SecurityGroupServerNotifierRpcMixin [1] Second with ResourcesPushRpcApi [2] Can someone involved in neutron code confirm that? It seems that, in OVS agent implementation, [1] is not used (my agent is not consuming those messages), but neutron server is sending messages in this exchange. This is why I have unroutable messages. [1] https://github.com/openstack/neutron/blob/3793f1f3888a85fc5e48c0e94e6a9f3c05... [2] https://github.com/openstack/neutron/blob/f8b990736ba91af098e467608c6dfa0b80... -- Arnaud Morin On 24.08.20 - 12:41, Arnaud Morin wrote:
Hey,
I did exactly the same on my side. I also have unroutable messages going in my alternate exchange, related to the same exchanges (q-agent-notifier-security_group-update_fanout, etc.)
Did you figured out why you have unroutable messages like this? Are you using a custom neutron driver?
Cheers,
-- Arnaud Morin
On 21.08.20 - 10:32, Fabian Zimmermann wrote:
Hi,
im currently on the way to analyse some rabbitmq-issues.
atm im taking a look on "unroutable messages", so I
* created an Alternative Exchange and Queue: "unroutable" * created a policy to send all unroutable msgs to this exchange/queue. * wrote a script to show me the msgs placed here.. currently I get
Seems like my neutron is placing msgs in these exchanges, but there is nobody listening/binding to: -- 20 Exchange: q-agent-notifier-network-delete_fanout, RoutingKey: 226 Exchange: q-agent-notifier-port-delete_fanout, RoutingKey: 88 Exchange: q-agent-notifier-port-update_fanout, RoutingKey: 388 Exchange: q-agent-notifier-security_group-update_fanout, RoutingKey: --
Is someone able to give me a hint where to look at / how to debug this?
Fabian