When a charm has a non-pristine status, it should leave the
previously-set blocked state (LP #1988088) if there are no
non-pristine disks
Also: seeing some spurious test failures due to timeouts
waiting on disk removal -- wait a bit longer
While the disk replacement rests are good for the OSD charm,
and it's useful to have more disks by default in that case,
requiring extra disk for all applications that tun the Ceph tests
is an unreasonable burden, requiring additional changed just
to accommodate the OSD charm tests.
This change updates to check if we have enough disks available
before running the disk replacement tests.
The compression mode after it's set via config-changed might take a
while to fully propagate to the whole cluster, hence the hook may be
done before the cluster is fully configured with the new compression
mode. This is more noticeable in the gate when there are many jobs
running in parallel.
This patch modes the check to its own method wrapped with a
tenacity.retry decorator to make the test more robust.
Closes#946
* Add functional tests for ceph-mon actions.
This PR adds functional validation for 2 actions of the ceph-mon
charm that are currently being rewritten.
Cleanup after the tests run.
Co-authored-by: Luciano Lo Giudice <luciano.logiudice@canonical.com>
In order to correctly test the upgrade from stable, we have to
move the tests that haven't landed yet to a different class so
that the charm can select to run them only after performing the
upgrade to the locally built charm.
The updated testcase handles verifying the expected states
that are safe to migrate, as well as verifying that pre- and post-
migration data are correctly synced.
Change prometheus test to check it has a non-zero amount of OSDs
registered rather than a specific number. This stops the number of
OSDs having to be managed in the tests.
With the upcoming transition to an operator-framework charm, the
Ceph tests need to be idempotent, since we'll be testing the upgrade
path from classical to operator. The tests that need fixing are the
ones that call out to add/remove disks, since they create loopback
devices to back the OSD's but never remove them.
There appears to be a race condition between the loop device creation
and its actual usage. In order to prevent that, this PR setups these
devices during the test initialization instead of right before using
them in the 'add-disk' tests.
This PR builds on the add-disk one, testing the complete flow
of adding a disk, removing it and finally re-adding it after
recycling the original OSD id.
This PR tests that a new device is succesfully added to the OSD
charm, and that it's done so via the 'bcache' mechanism. The
backing storage is provided via a loopback device, whereas the
caching storage is provided by Juju itself.
The test class BlueStoreCompressionCharmOperation gates tests on
whether the ceph release is mimic or newer but it uses the
keystone application to calculate the currently deployed version.
This PR switches the test class to ceck the version of ceph-mon
instead which makes more sense and the keystone application may
not always present in a ceph deployment.
Before this fix, the test tried to determine the OpenStack
release based on the ceph-mon charm. Unfortunately Ceph has
the same version on Ussuri and Victoria. As a consequence
the test would wrongly conclude that it's testing against
"groovy_ussuri", which isn't a valid Ubuntu/OpenStack pair.
With this fix, the test now determines the OpenStack
release based on the keystone charm, with which we are able
to tell Ussuri and Victoria apart. This test class is being
run against the following charm functional tests at the
moment, which all have a keystone charm in their test
bundles: nova-compute, cinder-ceph, glance, ceph-fs,
ceph-radosgw and gnocchi.