The root cause seems to be upstream in the dragent. It may never have been envisioned to run the agent by itself the way the charm does.
So that even if neutron-api completes its amqp relation first, eutron-dynamic-routing can still see
oslo_messaging.exceptions.MessagingTimeout errors. Some operation must occur against neutron before dragent is truly ready. i.e. some post deploy openstack command. So it is outside the purview of the charm.
The following changes add the amqp relation to neutron-dynamic-routing late. Post-deploy after networks have been configured. They are here for a proof of concept and request for comments:
This bug is in many ways a duplicate of https:/ /bugs.launchpad .net/charm- neutron- dynamic- routing/ +bug/1784083. The core root problem is the same.
The root cause seems to be upstream in the dragent. It may never have been envisioned to run the agent by itself the way the charm does.
So that even if neutron-api completes its amqp relation first, eutron- dynamic- routing can still see messaging. exceptions. MessagingTimeou t errors. Some operation must occur against neutron before dragent is truly ready. i.e. some post deploy openstack command. So it is outside the purview of the charm.
oslo_
The following changes add the amqp relation to neutron- dynamic- routing late. Post-deploy after networks have been configured. They are here for a proof of concept and request for comments:
https:/ /github. com/openstack- charmers/ zaza-openstack- tests/pull/ 155 /review. opendev. org/#/c/ 703207/
https:/