refac(gcp): model the data centers of a bootstrap - #625
Open
NJona wants to merge 2 commits into
Open
Conversation
NJona
force-pushed
the
multi-dc-03-datacenter-model
branch
from
August 4, 2026 08:12
6c7780b to
98bed26
Compare
NJona
force-pushed
the
multi-dc-03-datacenter-model
branch
from
August 5, 2026 15:48
98bed26 to
aacd865
Compare
joka134
requested changes
Aug 6, 2026
joka134
left a comment
Member
There was a problem hiding this comment.
looks good, but two questions
| } | ||
| } | ||
|
|
||
| // adoptLegacyEnvFields moves state that a caller supplied through the legacy top-level |
Member
There was a problem hiding this comment.
Are you planning to remove the legacy structs afterwards?
Member
Author
There was a problem hiding this comment.
Yes, and it now happens inside the stack. The mirror was a migration scaffold: PRs 4–7 still read Env.ControlPlaneNodes etc., so it has to stay through those. The new PR 11 (multi-dc-11-drop-legacy-env-mirror) deletes mirrorPrimaryDataCenter and its 8 call sites once nothing reads those fields. The fields themselves stay read-only — ensureDataCenters adopts them so an infra file from a pre-multi-DC OMS still works for cleanup/restart-vms — and got omitempty so new infra files don't write dead keys.
joka134
reviewed
Aug 6, 2026
NJona
force-pushed
the
multi-dc-03-datacenter-model
branch
from
August 7, 2026 16:03
aacd865 to
06e24fc
Compare
NJona
force-pushed
the
multi-dc-03-datacenter-model
branch
from
August 10, 2026 14:17
06e24fc to
62807bf
Compare
NJona
force-pushed
the
multi-dc-03-datacenter-model
branch
from
August 10, 2026 15:47
62807bf to
31eacb3
Compare
NJona
force-pushed
the
multi-dc-03-datacenter-model
branch
from
August 12, 2026 09:16
31eacb3 to
9b9a977
Compare
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. DataCenter references no GCP state, so it lives in the new internal/bootstrap/datacenter package where the other bootstrap flows can use it too. Deriving a layout from the GCP flags stays in the gcp package, since that is what differs per flow. 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 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, so the steps that still read them keep working while they are migrated. The last commit of the stack drops it again. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Jona Neef <Jona.Neef.97@gmail.com>
NJona
force-pushed
the
multi-dc-03-datacenter-model
branch
from
August 13, 2026 12:48
9b9a977 to
2c213fa
Compare
Signed-off-by: NJona <25478046+NJona@users.noreply.github.com>
joka134
approved these changes
Aug 13, 2026
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
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.