81f08ab769
Due to the @cache decorator in the code, it was possible to get the charm into a state where RMQ is clustered, but the charm doesn't record it. The charm 'thinks' it is clustered when it has set the 'clustered' key on the 'cluster' relation. Unfortunately, due to the @cached decorator it's possible in the 'cluster-relation-changed' hook to have a situation where the RMQ instance clusters during the hook execution and then, later, when it's supposed to writing the 'clustered' key, it reads the previous cached value where it wasn't clustered and therefore doesn't set the 'clustered' key. This is just about the only opportunity to do it, and so the charm ends up being locked. The fix was to clear the @cache values so that the nodes would be re-read, and this allows the charm to then write the 'clustered' key. Change-Id: I12be41a83323d150ba1cbaeef64041f0bb5e32ce Closes-Bug: #1975605 |
||
---|---|---|
.. | ||
lib | ||
amqp-relation-changed | ||
certificates-relation-changed | ||
certificates-relation-joined | ||
cluster-relation-broken | ||
cluster-relation-changed | ||
cluster-relation-joined | ||
config-changed | ||
dashboards-relation-joined | ||
ha-relation-changed | ||
ha-relation-joined | ||
install | ||
install.real | ||
leader-deposed | ||
leader-elected | ||
leader-settings-changed | ||
nrpe-external-master-relation-changed | ||
post-series-upgrade | ||
pre-series-upgrade | ||
prometheus-rules-relation-created | ||
prometheus-rules-relation-joined | ||
rabbit_net_utils.py | ||
rabbit_utils.py | ||
rabbitmq_context.py | ||
rabbitmq_server_relations.py | ||
scrape-relation-broken | ||
scrape-relation-created | ||
scrape-relation-joined | ||
ssl_utils.py | ||
start | ||
stop | ||
update-status | ||
upgrade-charm | ||
upgrade-charm.real |