For some reason test cases are sometimes executed out of order and so
test_921_remove_unit is sometimes run before the pause_and_resume test
case which results in an error.
While the root cause for it must be found it would also be good to avoid
side-effects in individual test cases and return the environment back to
its original state.
There is no 'start' hook implementation for charm-rabbitmq-server,
however, changes that close to the 20.05 release are discouraged so this
change uses an upgrade-charm event simulation to re-trigger the addition
of a unit (which was previously removed) to the cluster.
NOTE: after an execution of hooks/upgrade-charm finishes, the charm will
stay in the waiting state with the following status until the next
update-status event: 'Unit has peers, but RabbitMQ not clustered'
Related-Bug: #1730709
By including pre and pos-application functions, charm
series upgrades can be handled in a more generic way,
even when they require running additional actions
before a unit is upgraded, or after the whole application
is upgraded.
Ubuntu focal ships with rabbitmq server 3.8.2 which has changed the text
output format for the cli commands that the tests rely on. Fortunately,
3.8.2 also adds a --formatter=json option. This patch takes advantage
of that.
This function was previously called test_901_remove_unit, but had to
be renamed (moved to the end of the func tests); The way in which unit
removal is now performed (by running the "stop" hook) puts the the
removed unit in a "waiting" state -- which consequently causes
wait_for_cluster() (e.g. used in 910) to fail (timeout).
Same message as my previous commit: As per the code: is there a
function to determine unit's release? Otherwise, I'll just implement
a generic function that run_on_unit lsb_release -cs
Note: This test may have exposed a bug, where the
`block_until_unit_wl_status` returns once it reaches the "maintenance"
state, but subsequent queries to `unit.workload_status ==
"maintenance"` fail. Recreating the unit object (via
`zaza.model.get_unit_from_name`) returns the correct workload_status
when queried.