It appears that this binding [1] exists in rabbitmq, but rabbitmq is ignoring it, and when messages come in on the neutron exchange with topic q-l3-plugin, it does not send them to the q-l3-queue.
I see a similar launchpad [2] opened back in 2017 in the Mirantis OpenStack Project that hasn't been updated since.
By setting the alternative-exchange to q-l3-plugin_fanout[3], the system becomes functional again, which confirms that the issue is with the routing inside of rabbitmq. When I move the alternative exchange away from q-l3-plugin_fanout again, the rpc starts failing again.
I looked for upstream bug reports in oslo.messaging and neutron, but I didn't see any reports of this. I don't see this issue open upstream for rabbitmq-server either.
These RPCs are getting lost inside of rabbitmq.
It appears that this binding [1] exists in rabbitmq, but rabbitmq is ignoring it, and when messages come in on the neutron exchange with topic q-l3-plugin, it does not send them to the q-l3-queue.
I see a similar launchpad [2] opened back in 2017 in the Mirantis OpenStack Project that hasn't been updated since.
By setting the alternative- exchange to q-l3-plugin_ fanout[ 3], the system becomes functional again, which confirms that the issue is with the routing inside of rabbitmq. When I move the alternative exchange away from q-l3-plugin_fanout again, the rpc starts failing again.
I looked for upstream bug reports in oslo.messaging and neutron, but I didn't see any reports of this. I don't see this issue open upstream for rabbitmq-server either.
[1] neutron exchange q-l3-plugin queue q-l3-plugin [] /bugs.launchpad .net/mos/ +bug/1696397 exchange" :"q-l3- plugin_ fanout" }'
[2] https:/
[3] rabbitmqctl -p neutron set_policy AE "neutron" '{"alternate-