hashicorp / hashicorp/vault-helm
`server.ha.raft.setNodeId` rationale?
- Dominant language
- Shell
- Stars
- 1.3k
- Forks
- 898
- Avg merge
- 3d 1h
- Merged PRs (30d)
- 1
Description
This Helm chart provides the boolean value `server.ha.raft.setNodeId`.
However, I have found no documentation that explains why you would or would not want to use it - so I have been studying the topic trying to figure it out for myself.
To recap the behaviour:
* If false (the default), the Raft node IDs will be generated UUIDs, persisted in the PVs.
* If true, the Raft node IDs will be the pod names.
This will only cause a significant behaviour difference, when a pod is restarted **with loss of its PV data**.
* If `setNodeId` is false, the new pod will be treated as a brand new node.
* If `setNodeId` is true, the new pod will implicitly replace the old one in the Raft configuration.
Here is where I'm slightly uncertain... **is it actually safe** for a Raft node to lose all its data, and still claim to the rest of the Raft cluster that it is the same node, to which data was in the past committed?
Is anyone able to comment on the history and rationale of the `setNodeId` value being configurable, so as to build a consensus which could be turned into documentation to clarify this point once and for all?
Contributor guide
Research direction
Start by locating the Helm chart configuration and documentation for `server.ha.raft.setNodeId`, then review the issue's described behavior and existing discussion. The work is done when maintainers agree on the rationale and the chart documentation clearly explains when each setting is appropriate and what happens after PV data loss.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kubernetes
- Domain
- documentation, infrastructure
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100