Charm update-status fails after scaling in operation
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack RabbitMQ Server Charm |
Triaged
|
Medium
|
Unassigned |
Bug Description
I installed Openstack using openstack-base with openstack-
I scaled rabbitmq-server charm out and in two times.
At the end of the second scale in operation, rabbitmq-server/0 stayed in hook failed: "update-status".
Steps
-----
# Scale out and wait for it to finish
juju add-unit -n3 rabbitmq-server
watch -n1 -c juju status rabbitmq-server --color
# Scale in and wait for it to finish
juju remove-unit rabbitmq-server/1 rabbitmq-server/2 rabbitmq-server/3
watch -n1 -c juju status rabbitmq-server --color
# Scale out and wait for it to finish
juju add-unit -n3 rabbitmq-server
watch -n1 -c juju status rabbitmq-server --color
# Scale in and wait for it to finish
juju remove-unit rabbitmq-server/4 rabbitmq-server/5 rabbitmq-server/6
watch -n1 -c juju status rabbitmq-server --color
-----
Note: I waited for all units to reach a stable state between executing commands.
Once it finishes, juju status shows the following:
rabbitmq-
From logs
---------
INFO juju-log Updating status.
DEBUG juju-log check_cluster_
DEBUG juju-log Running ['/usr/
DEBUG update-status Removing node 'rabbit@
DEBUG update-status Error: {not_a_
DEBUG update-status Traceback (most recent call last):
DEBUG update-status File "/var/lib/
DEBUG update-status hooks.execute(
DEBUG update-status File "/var/lib/
DEBUG update-status self._hooks[
DEBUG update-status File "/var/lib/
DEBUG update-status return f(*args, **kwargs)
DEBUG update-status File "/var/lib/
DEBUG update-status rabbit.
DEBUG update-status File "/var/lib/
DEBUG update-status forget_
DEBUG update-status File "/var/lib/
DEBUG update-status rabbitmqctl(
DEBUG update-status File "/var/lib/
DEBUG update-status subprocess.
DEBUG update-status File "/usr/lib/
DEBUG update-status raise CalledProcessEr
DEBUG update-status subprocess.
ERROR juju.worker.
---------
This may be an issue with documentation or other; it's not clear whether the configuration options of the charm were changed so that the rabbitmq-server expected the to reduce the cluster size below the minimum (min-cluster- size?). Rabbitmq also doesn't really 'like' even cluster sizes -- it's not clear but it seemed to be '6'. Also for rabbitmq reasonable cluster sizes are 3.
Having said that, there was a hook-error, and charms should not error out; they should report the failure in the log and status line as appropriate.