Heat charm when configured with traefik-route
can have multiple loadbalancers (for heat-api
and heat-api-cfn).
So remove the assertion in wait_for_traefik on
number of loadbalancers. Check on number of units
against number of servers should be sufficient.
Traefik config file names are of format
juju_ingress_ingress_<id>_<app>.yaml for
ingress interface. However if traefik_route
interface is used, the file name format
is juju_ingress_traefik-route_<id>_<app>.yamlwq
In tempest tests, wait_for_traefik, change the
filename format to support both ingress and
traefik-route interfaces.
The nova service may not be quite ready after vault initialisation for
the basic network configuration, so add a retrier wrapper around the
client for every test to make sure that it retries.
Updates charm upgrades to use channels, tracks, and risks instead
of URLs.
Currently these tests only upgrade OpenStack charms and packages.
The OVN, ceph, and misc charms and payloads are not upgraded.
Remove instance creation since tempest can be used to verify the
cloud.
The serial config can be set to True to add the --serial flag to the
tempest run. This appears to be useful with the current state of
serverstack and fixing tests that fail due to "Bad router request:
Router already has a port on subnet <subnet-uuid>."
Some endpoints (heat) return 401s if you try and access them
without authenticating. Given the ep has been able to verify
whether you are authenticated a 401 is ok for a rudementary
health check
Recent test runs have shown that the current number of retries is
not enough and traefik has still not updated its config. This PR
increases the number of retries in the hope that it will be
enough.
Add tactical work around for traefik readyness. Traefik takes
sometime to process changes to load balancer configuration.
Traefik has an api but it is turned off by default and currently
the charm does not expose a way to enable it. So, this change
looks at the traefik config on disk to check if it has the
correct number if units.
Tempest will by default run with a concurrency matching the
number of cores on the test runner.
When running on a workstation, it is likely that the default
concurrency will be too high for the scale of deployed workload.
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Traefik might take some time to update its configuration,
and switch multiple times between active and maintenance for the duration.
Waiting only for tests is not enough. This change introduce a wait
for endpoints to be ready.
Moreover, at glance call to setup the image might fail because of this
very reason, add a retry on render_tempest_config_keystone_v3.
Let the units run all the hooks before attempting to check if the ring
is synced, because the action set-weight triggers the hook
swift-storage-relation-changed in the swift-storage units which it's the
one in charge of getting the new ring data.
Replace "assert type(...) is Foo" with "self.assertIsInstance(..., Foo)"
this produces a more meaningful test error message and fixes pep8 rule
E721[0]
[0] https://www.flake8rules.com/rules/E721.html
The existing order of operations after restarting the share is:
1. mount share on ins-1
2. validate the test file on ins-1
3. mount share on ins-2
4. clear the test file using 'rm' on ins-1
5. write the test file on ins-1
6. read the test file on ins-2
The issue is that step 4. can result in a stale file handle on ins-2
which takes an unspecified amount of time to clear. Mounting the share
on ins-2 after the file is re-written does however work without a stale
file handle. The new order is:
1. mount share on ins-1
2. validate the test file on ins-1
3. clear the test file using 'rm' on ins-1
4. write the test file on ins-1
5. mount share on ins-2
6. read the test file on ins-2
Closes-Bug: #1107
When running the pool setup we test after the model is idle, but that
is not a guarantee that all pools have finished setup, so that the test
could race the pool creation.
Add retry to the test to give the system another chance to complete
pool creation
This test launches 1 instance per hypervisor, and then launches a new
audit to optimize the use of hypervisors and consolidate the instances
in a single hypervisor, but also disabling the nova-compute service to
avoid new instances get allocated.
