The ML2 plugin initializes some RPC notifiers (for agents), which consequently declare some exchanges in the RabbitMQ server.
https://opendev.org/openstack/neutron/src/commit/dd3853007bb36999d391a823505fbe0c279d2317/neutron/plugins/ml2/rpc.py#L456
Two of these exchanges are:
– `q-agent-notifier-port-update_fanout`
– `q-agent-notifier-port-delete_fanout`
For the `q-agent-notifier-port-update_fanout` exchange, some agents like linuxbridge, macvtap and sriovnic create the corresponding consumers.
https://opendev.org/openstack/neutron/src/commit/dd3853007bb36999d391a823505fbe0c279d2317/neutron/plugins/ml2/drivers/mech_sriov/agent/sriov_nic_agent.py#L218
https://opendev.org/openstack/neutron/src/commit/dd3853007bb36999d391a823505fbe0c279d2317/neutron/plugins/ml2/drivers/macvtap/agent/macvtap_neutron_agent.py#L149
https://opendev.org/openstack/neutron/src/commit/dd3853007bb36999d391a823505fbe0c279d2317/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py#L830
For the `q-agent-notifier-port-delete_fanout exchange`, I cannot find any agent that implements the corresponding consumer. If agents do not implement that consumer, the corresponding queue is not created in RabbitMQ (and therefore there is no exchange-to-queue binding). Consequently, when a Neutron port (when using OVS mech driver, for example) is deleted, a message is sent to the `q-agent-notifier-port-delete_fanout` exchange, and the broker considers it an unroutable message and drops it.
In some large environments, if the necessary queues/consumers are not present, deleting or updating Neutron ports can lead to an increase in RabbitMQ’s unroutable messages metrics, which may erroneously suggest performance issues with the RabbitMQ server.
Is there a way to avoid initializing RabbitMQ exchanges that will not actually be used?
Read more here: Source link
