yahoo-eng-team team mailing list archive

[German E <2080314@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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?

** Affects: neutron
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2080314

Title:
  ML2 plugin: No consumers for q-agent-notifier-port-delete_fanout
  exchange result in unroutable RabbitMQ messages

Status in neutron:
  New

Bug description:
  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?

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2080314/+subscriptions