refac(gcp): model the data centers of a bootstrap - #625
Open
NJona wants to merge 1 commit into
Open
Conversation
Until now a bootstrapped project was implicitly a single data center: its nodes, gateway IPs, config paths and domains all lived directly on CodesphereEnvironment. Multi-DC support needs more than one of each, so this introduces the DataCenter type that holds everything which must differ per data center, while project-level state (project, VPC, jumpbox, shared postgres node, registry) stays on the environment. BuildDataCenters derives the layout from the flags: one entry today, and with --multi-dc a second one that shares the first's PostgreSQL server. The primary data center keeps an empty resource-name suffix, so every name, path and domain a single-DC bootstrap produces is unchanged. Nothing consumes the layout yet — the callers are migrated in the following commits. Two mechanisms keep that migration safe: - ensureDataCenters derives the layout on first use and adopts state a caller passed through the legacy top-level environment fields, so every entry point works whether or not Bootstrap ran first, including infra files written before multi-DC support. - mirrorPrimaryDataCenter projects the primary data center back onto those fields before the infra file is written, so cleanup and restart-vms keep reading what they always have. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Jona Neef <Jona.Neef.97@gmail.com>
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
1 participant
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.
Until now a bootstrapped project was implicitly a single data center: its nodes, gateway IPs, config paths and domains all lived directly on
CodesphereEnvironment. Multi-DC needs more than one of each, so this introduces theDataCentertype holding everything that must differ per data center, while project-level state (project, VPC, jumpbox, shared postgres node, registry) stays on the environment.BuildDataCentersderives the layout from the flags: one entry today, and with--multi-dca second one that shares the first's PostgreSQL server. The primary data center keeps an empty resource-name suffix, so every name, path and domain a single-DC bootstrap produces is unchanged.Review notes
Nothing consumes the layout yet — the callers are migrated in the following PRs. Two mechanisms keep that migration safe:
ensureDataCentersderives the layout on first use and adopts state a caller passed through the legacy top-level environment fields, so every entry point works whether or notBootstrapran first — including infra files written before multi-DC support.mirrorPrimaryDataCenterprojects the primary data center back onto those fields before the infra file is written, socleanupandrestart-vmskeep reading what they always have. The projection is one-way and never read back.Part of the
oms beta bootstrap-gcp --multi-dcstack (10 PRs). Merge in order; each PR is based on its predecessor.