Repository navigation
Match staging compute and ingress topology to production - #1751
Merged
Merged
Conversation
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.
Staging currently has two e2-standard-2 nodes and one ingress/cache replica, while production has two e2-standard-4 nodes and two ingress replicas. Those differences limit how confidently staging burst tests predict production capacity.
Configure staging permanently with e2-standard-4 nodes and two ingress replicas, retaining the existing two-node pool, 50-GB boot disks, PostgreSQL limits/settings and application resources. Update the deployment documentation to describe the shared sizing.
Validation:
make -C deploy buildandgit diff --checkpassed. Refreshed Pulumi previews for both stacks completed against isolated copies of their checkpoints. Staging shows an update of the existing node pool (machine type only), ingress scaling from one to two, and the chart's corresponding PodDisruptionBudget; no cluster or node-pool replacement. Existing Helm admission-hook/RBAC reconciliation also appears. The production preview has no capacity/topology change from this patch. Regional surge quota was checked and no competing GKE operation was active.Rollout recreates staging nodes using the existing surge policy, so its single PostgreSQL instances can briefly be unavailable while volumes reattach. The staging registry table has a verified production-data copy and a retained logical snapshot. After staging settles, repeat the same baseline/candidate burst tests; this PR does not release or promote the application to production.