Comment 9 for bug 1975605

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to charm-rabbitmq-server (stable/jammy)

Reviewed: https://review.opendev.org/c/openstack/charm-rabbitmq-server/+/869455
Committed: https://opendev.org/openstack/charm-rabbitmq-server/commit/8f1986b8b583c81e3351b19eea29988c3ce83715
Submitter: "Zuul (22348)"
Branch: stable/jammy

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)