Closed juditnovak closed 2 months ago
Thank you for reporting us your feedback!
The internal ticket has been created: https://warthogs.atlassian.net/browse/DPE-5316.
This message was autogenerated
@juditnovak this issue is caused by the fact we have a single-node cluster and, at removal, it will clean its databag before running the final events and being eventually destroyed. Juju usptream issue: https://bugs.launchpad.net/juju/+bug/2076599
What you have here is the same problem as: canonical/opensearch-operator#444
Which means you have: (1) a start event being deferred; (2) you remove the unit or app; and (3) the start will not be able to succeed anymore. Closing this bug as we have fixed this problem. Feel free to re-open if we see it again.
The issue occured when removing units from a non-established cluster. Thus the low priority. Intermittent issue, non-deterministic.
NOTE: Though one of the units concerned is IPv6, I it seems independent from the issue -- due to fully equal behavior experienced on the IPv4 unit equally.
Both peer units believe that the other one is still in the peer relation (see peer relation data below). While neither would find itself in the peer relation thus unable to determine
deployment-description
.Steps to reproduce
opensearch
in a way the cluster is not established (see issue https://github.com/canonical/opensearch-operator/issues/416)juju remove-unit opensearch/N
QUICKLY one after the other each unit.Actual behavior
unit openserach/24:
unit opensearch/25:
Versions
Operating system:
Juju CLI:
Juju agent:
Charm revision:
LXD:
Log output
Juju debug log, as indicated above:
Additional context
Debugger output confirming the missing relation: