Repository navigation
fix: (rollingops) dynamic cluster ID - #706
Merged
patriciareinoso merged 20 commits intoOct 7, 2026
Merged
Conversation
patriciareinoso
marked this pull request as ready for review
October 5, 2026 14:53
Mehdi-Bendriss
approved these changes
Oct 5, 2026
patriciareinoso
marked this pull request as draft
October 6, 2026 10:19
patriciareinoso
marked this pull request as ready for review
October 6, 2026 15:54
Removed redundant comments for clarity.
Gu1nness
reviewed
Oct 7, 2026
Gu1nness
approved these changes
Oct 7, 2026
patriciareinoso
deleted the
DPE-11212-rollingops-fix-dynamic-cluster-id
branch
October 7, 2026 13:59
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix #684
Problem
If the etcd relation is created before the charm has a
cluster_id, the etcd backend never gets set up. Oncecluster_idbecomes available later, therelation-createdhook that would normally publish the request has already fired and won't fire again, so etcd never is configured, and the unit stays stuck on the peer backend.Fix
EtcdRequiresV1.ensure_request_published(), called in the_EtcdRollingOpsBackendconstructor. It writes the request for an existing relation if it hasn't been published yet, using the publicdpcharmlibs.interfaceshelpers.EtcdRequiresV1is constructed. Previously the cert was created after, so the first published request was always missing it, which etcd rejects with "Missing certificate or prefix"toggle-cluster-idaction to the integration test charms to manually reproduce/verify this race.Testing
tests/unit/test_etcd_dynamic_cluster_id.py:cluster_idisNonecluster_idbecomes availablesecret-mtls), guarding against the ordering bug aboverequest_id, derived from a random salt, stays stable across repeated calls)Manual test
The fix was manually tested for same-model and cross-model relations