Skip to content

feat(installer): config and vault primitives for multiple data centers - #623

Open
NJona wants to merge 2 commits into
mainfrom
multi-dc-01-installer-primitives
Open

feat(installer): config and vault primitives for multiple data centers#623
NJona wants to merge 2 commits into
mainfrom
multi-dc-01-installer-primitives

Conversation

@NJona

@NJona NJona commented Jul 31, 2026

Copy link
Copy Markdown
Member

Groundwork for multi-data-center support, with no behaviour change for existing callers.

  • InstallVault.RemoveSecret and InstallVault.Clone, so a vault can be derived from another one instead of generated from scratch.
  • RootConfig.Clone, a YAML round-trip deep copy.
  • The installer's dataCenters and defaultDataCenterId keys, which declare the topology of the installation. Both are omitempty, so a single-data-center config serialises exactly as before.
  • InstallConfigManager.SetInstallConfig / SetVault, so a caller can seed a manager from a source other than a profile or a file.
  • files.PostgresUserSecretName / PostgresPasswordSecretName, so the per-service postgres secret names have a single definition.

Review notes

Nothing consumes any of this yet — it is all additive.

Part of the oms beta bootstrap-gcp --multi-dc stack (10 PRs). Merge in order; each PR is based on its predecessor.

NJona and others added 2 commits July 31, 2026 14:19
Adds what a multi-data-center installation needs from the config and
vault types, without any behaviour change for existing callers:

- InstallVault.RemoveSecret and InstallVault.Clone, so a vault can be
  derived from another one instead of generated from scratch.
- RootConfig.Clone, a YAML round-trip deep copy.
- The installer's dataCenters and defaultDataCenterId keys, which
  declare the topology of the installation. Both are omitempty, so a
  single-data-center config serialises exactly as before.
- InstallConfigManager.SetInstallConfig/SetVault, so a caller can seed a
  manager from another source than a profile or a file.
- files.PostgresUserSecretName/PostgresPasswordSecretName, so the
  per-service postgres secret names have one definition.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Jona Neef <Jona.Neef.97@gmail.com>
Signed-off-by: NJona <25478046+NJona@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant