commit 8f1986b8b583c81e3351b19eea29988c3ce83715
Author: Alex Kavanagh <email address hidden>
Date: Fri Dec 23 13:20:34 2022 +0000
Fix issue where charms aren't clustered but RMQ is
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
(cherry picked from commit 81f08ab7695ab507ade076c33d0cc168a03be221)
Reviewed: https:/ /review. opendev. org/c/openstack /charm- rabbitmq- server/ +/869455 /opendev. org/openstack/ charm-rabbitmq- server/ commit/ 8f1986b8b583c81 e3351b19eea2998 8c3ce83715
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/jammy
commit 8f1986b8b583c81 e3351b19eea2998 8c3ce83715
Author: Alex Kavanagh <email address hidden>
Date: Fri Dec 23 13:20:34 2022 +0000
Fix issue where charms aren't clustered but RMQ is
Due to the @cache decorator in the code, it was possible to get the relation- changed' hook to have a
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-
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: I12be41a83323d1 50ba1cbaeef6404 1f0bb5e32ce 7ade076c33d0cc1 68a03be221)
Closes-Bug: #1975605
(cherry picked from commit 81f08ab7695ab50