The configure step for the DRAgent tests configures a name for a
floating IP to be checked for at the peer side. Since the data plane
tests add one as well for an instance, make sure the control plane-only
tests rely on the FIP that has a specific name. This can be useful if
the tests are run in a different order.
A separate service subnet for FIPs is useful in making sure that
connectivity based on the advertised routes really works as opposed to
relying on directly connected routes to FIPs in the undercloud network
subnet used as an external network.
As a prerequisite to testing the data plane connectivity with routes
advertised by NDR, this change makes the configuration step reuse the
existing network config code that is able to do things like plugging an
extra interface to be used in bridge-interface-mappings.
A charm that uses FRR instead of Quagga is now published under:
https://charmhub.io/osci-frr
For our purposes FRR is a drop-in replacement of Quagga but the point
of a change is to remove Quagga references for clarity.
Previous attempts to fix LP Bug#1784083 added a workaround (commit
820ed808) which is being removed here.
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,
neutron-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.
This change adds a service restart late.
Partial-Bug: #1841459