The current implementation may miss waiting for config change to
actually happen as it in some circumstances jumps to waiting for a
idle state prior to the model executing anything.
Add a wait for agent status `executing` immediatelly after config
change to avoid this.
Fixes#123
It would be awesome if the first iteration of a ARP lookup, ICMP
echo and ICMP reply on a newly created instance was always
successful. Sadly this is not the reality.
Increase wait attempts for availability of volume created from image
in CephRBDMirrorTest. This is taking longer as of Nautilus due to
switch to using juju storage backed by undercloud cinder taking
longer than prior method of directory-backed OSD devices.
We are stuck with juju_wait until we figure out how to deal with
all the non ['active', 'idle', 'Unit is ready.'] workload/agent
states and msgs that our mojo specs are exposed to.
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.
The SwiftImageCreateTest was running a pause/resume test for
swift proxy which does not make sense. So, break the proxy specific
tests into their own class and add a class for storage. A
subsequent change to the swift-proxy charm will be needed to add
the new proxy test class to the tests.yaml.
* Move code into test_410_heat_stack...() instead of calling functions
* Use glance and nova helper functions as available
* Simplify method for detecting duplicate encryption keys
It turns out we do need to set DNS on the overcloud subnet. It should be
the .2 of the CIDR under test and not the _admin_net's .2. There seems
there are security group rules in the way.
Make it possible for consumers of the ``auto_initialize_no_validation``
function to execute subsequent setup and test code that require vault
and the consumers of the ``certificates`` relation to be ready.
With the current order of execution, it is not possible to use the
configure function in models where ``keystone`` application is not
present.