Clarify the role of Cluster ID and other inputs #6
Conversation
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
Remove the expectation that forcing a new cluster-of-one always results in a new "cluster ID", as the cluster ID is generated from the member information, so if you create the exact same cluster from the same members, it will yield the same cluster id.
Include "current cluster state" and removed "version counter". Signed-off-by: Carlo Lobrano <[email protected]>
beekhof
reviewed
Feb 3, 2025
| @@ -125,7 +125,7 @@ Upon rebooting, the RHEL-HA components ensure that a node remains inert (not run | |||
| If the failed peer is likely to remain offline for an extended period, admin confirmation is required on the remaining node to allow it to start OpenShift. | |||
| This functionality exists within RHEL-HA, but a wrapper will be provided to take care of the details. | |||
|
|
|||
| When starting etcd, the OCF script will use etcd's cluster ID and version counter to determine whether the existing data directory can be reused, or must be erased before joining an active peer. | |||
| When starting etcd, the OCF script will use data on disk (e.g. etcd's cluster ID) and the current state of the cluster (e.g. which resource agent is already running) to determine whether the existing data directory can be reused, or must be erased before joining an active peer. | |||
There was a problem hiding this comment.
I would have thought the reverse... that the cluster ID was almost useless, and the version counter the only interesting/useful detail
There was a problem hiding this comment.
The cluster ID is still the only source on disk to understand if the peer node has forced a new cluster while the starting node was stopped, so, even if it is expected to be the same most of the time, I would still consider valuable to check on its value at startup.
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.
It came to my attention recently that the Cluster ID number is the outcome of member information, so forcing a new cluster does not automatically means getting a new Cluster ID.
I clarified this information in the EP.
Moreover, in the same context, I included the "current cluster state" as information that the Etcd agent might use to decide whether to reuse or drop Etcd data directory at reboot.