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.
The neutron ``basic_overcloud_network`` setup job performs both
undercloud and charm configuration prior to configuring the
overcloud network. The undercloud and charm configuration steps
are useful outside the context of OpenStack Neutron.
Split undercloud and charm setup into a new configure step.
This adds a new setup function that will setup a VLAN provider network.
It can be called by tests.yaml after basic_overcloud_network:
- zaza.openstack.charm_tests.neutron.setup.basic_overcloud_network
- zaza.openstack.charm_tests.neutron.setup.vlan_provider_overcloud_network
When on MAAS support doing charm based configuration of OVS by
retrieving MAC address of ports attached to external network
from MAAS.
Note that we should extend the MAAS support to also work with
deployments where MAAS does the OVS configuration for us.
A recent change introduced a configuration option in the
./tests/test.yaml file (default location) which allows juju wait to be
used rather than waiting on various workload messages. This,
unfortunately, breaks mojo tests as they don't use a tests.yaml. This
change refactors that code, and enables a 'use_juju_wait' to be passed
into the relevant functions, and a new command line option (default
true) to disable using juju wait.
This is useful for validating deployments with OVN where it is not
required to have external networking attached to every chassis.
Any chassis that does not have external networking directly
attached will forward traffic destined for the external network
through a tunnel to a chassis that does.
Dmitrii Shcherbakov
Bas de Bruijne
Frode Nordahl
Aurelien Lourot
coreycb
Alex Kavanagh
Chris MacNaughton