-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Allow validators to use the same config file #5176
Description
Description
Explain in detail the additional functionality you would like to see in stellar-core.
Currently, when somebody wants to configure multiple full validators, they end up with each of them having slightly different config:
- NODE_SEED is different on each system (already tracked under Move secrets out of the config file #1316)
- Each system does not have itself listed in the quorumset
- Each system has different HISTORY config
It would be convenient if we had a way to deploy common config to all nodes. In my case it would help with deploying validators in k8s but it should benefit non-k8s deployments too.
Explain why this feature is important
In case of k8s the fact that validators need different configs means we need to create separate ConfigMap for each node and assign appropriately. The differences also mean that config updates are harder as operators need to edit multiple configs.
Describe the solution you'd like
NODE_SEED work is tracked under #1316
For quorumset I think we should be able to configure all validators on every system and have core code use NODE_SEED to ignore itself in the config.
To help with the history difference I think we could use a similar method to quorumset. Configure “put” command for every quorumset member. Core could skip this option for every quorumset member where PUBLIC_KEY doesn't match NODE_SEED. This means that hisotry config would need to move to the VALIDATORS section. We'd also need to find a way to run "new-hist". Perhaps "new-hist self" or similar should parse config and initialize all relevant archives.
Describe alternatives you've considered
Without such functionality operators need to maintain separate configs.
Additional context
- It would be safest for core should keep support for the current config format
- There are still valid reasons why somebody may choose to use different config. For example it may be desirable to have different INVARIANT_CHECKS on some nodes. So it should still be possible to do so