## Context Raised in [handbook MR review](https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/19292/diffs) and discussed in [Slack thread](https://gitlab.slack.com/archives/C0A178WB19V/p1775822202850749). The GKG infrastructure Terraform configs in `config-mgmt` (`environments/orbit-stg`, `environments/orbit-prd`) were duplicated rather than extracted into reusable modules. This happened because the team was following existing analytics cluster patterns, dealing with novel PSC-over-TLS connectivity (never done at GitLab before), and working under tight deployment timelines. ## Problem Duplicated Terraform environments are a one-way door: the longer they remain as-is, the more staging and production drift apart. This pattern also does not scale to Dedicated or Cells deployments. ## Proposed approach Per @andrewn guidance: 1. Move all differences between `orbit-prd` and `orbit-stg` into input variables 2. Extract the shared Terraform config into a new reusable module (potentially using the [template generator](https://copier-gif-b4e288.gitlab.io/)) 3. Integrate the module back into `orbit-prd` and `orbit-stg` with appropriate variables 4. Add `moved` blocks so Terraform does not tear down existing infrastructure 5. Set up Renovate to send MRs when new module versions are published This can be done without tearing down the environment, though it requires care. ## Open questions - Which repo should own the new module? (team-owned vs `../components/`) - Coordination needed with analytics team (`data-insights-platform-infra`) since patterns are shared - Scoping the work effort to determine if it can happen before or after initial production deployment ## Slack conversation <details> <summary>Full thread from #f_knowledge_graph_dev (2026-04-10)</summary> **Brian Greene** (11:56): > @Angelo Rivera @Bohdan https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/19292/diffs **Angelo Rivera** (13:41): > Awesome thank you @bgreene - let's start a chat with @andrew and @stejacks about it **Angelo Rivera** (13:57): > **Copypasta development: duplicating Terraform or Helm configurations instead of using modules.** > > From what I can tell, we did this because we: > > - were following the previous analytics cluster pattern > - we were told that this will be in a new cluster, and this new cluster will connect via PSC to rails over TLS, which has never been done at gitlab before > - there weren't patterns to replicate before > - team had to figure a lot of stuff out > > Agreed with the duplication point overall, and there are likely better ways we could have handled it. > > @andrew @stejacks questions that we can get help answered: > > - what do we exactly need to clean up and turn into re-usable modules? > - what exactly do we need to pull out of ops.gitlab.net that should be in the other repos? > - what is the work effort required to do it the right way? > > If the last question is a significant lift, as in anything longer than a day of Dev time, I'd challenge us to see if we can perform cleanup/migration after we've deployed GKG to production. We are supposed to deploy next Wednesday (but we pushed back a week or two). **Andrew Newdigate** (14:04): > @Angelo Rivera anything that you can express in the root module `environments/orbit-stg` you can also express as a Terraform Module. There is no difference in functionality -- so if you've been able to do this in `environments/orbit-stg` that means we can extract it out into a separate module which the team owns, has linters, checkov guardrails, and most importantly, can be reused between production, staging, cells, dedicated, etc. > > So, to do this is a fairly straight-forward refactor. We could even do it without tearing the environment down, although this will take a little more care. **Angelo Rivera** (14:11): > ^ @Arun Sori @ahegyi @Ankit Bhatnagar **Andrew Newdigate** (14:12): > You could setup the project using the template generator: https://copier-gif-b4e288.gitlab.io/ (this is experimental -- you can also do this from the command line using instructions from https://gitlab.com/gitlab-com/gl-infra/common-template-copier). > > I think we should speak to @stejacks before doing anything, but if you create a temporary sandbox project we can get Duo/Claude to do the heavy lifting of: > > 1. Moving all the differences between the orbit-prd and orbit-stg projects into input variables > 2. Extracting the module to the new location > 3. Integrating the module into orbit-prd and orbit-stg with appropriate variables. > 4. Add moved blocks to orbit-prd and orbit-stg to ensure that Terraform doesn't tear your existing infra down > 5. Get Renovate to send MRs when new versions of your module are published. > > I don't think this is a big deal, although the current approach is a one-way door... the longer you leave it as is, the less chance there is of us moving to a separate module as the environments will drift over time, etc **Angelo Rivera** (14:13): > Where do these new modules live? > > like which repo? > > because this is shared with both analytics team and gkg team **Arun Sori** (14:15): > Not sure how this comes into play but DIP/Analytics infrastructure did have its own module https://gitlab.com/gitlab-org/analytics-section/platform-insights/data-insights-platform-infra > > However some of the connection bits like vault, PSC options exist outside of this simply because they were harder to modularize **Andrew Newdigate** (14:15): > The COM handbook page originally said `../components/` but I think we don't need to stick to this. I think having stronger ownership with team groups might be better. **Andrew Newdigate** (14:16): > @Arun Sori can you provide more details of things that were harder to modularise? Terraform inputs can be secrets, these can come from vault... just trying to understand the problem a little better **Arun Sori** (14:23): > @andrew So it has been some time so my knowledge is not fresh but I think we can look at config-mgmt for actual things that we could or could not modularize: > > - https://ops.gitlab.net/gitlab-com/gl-infra/config-mgmt/-/blob/main/environments/analytics-eventsdot-stg/logging.tf > - https://ops.gitlab.net/gitlab-com/gl-infra/config-mgmt/-/blob/main/environments/analytics-eventsdot-stg/private-service-connect.tf#L105 > - https://ops.gitlab.net/gitlab-com/gl-infra/config-mgmt/-/blob/main/environments/analytics-eventsdot-stg/gke-ingress.tf > > Are some of the examples. > > Also, I think the practice of having the module elsewhere and the actual config different also sometimes lead to us pushing things directly on config-mgmt as it just becomes a cognitive exercise to see if we should add resources to modules instead. This becomes particularly relevant when we are chasing some very tight timelines such as GKG rollout. **Andrew Newdigate** (14:27): > @Arun Sori having a copy of the definition for each environment is not scalable. right now you're only thinking about (legacy) .com staging and production. Soon you'll also need to be thinking about Dedicated, Cells, etc. Having a single module which can be deployed in many places is a bit more cognitive load, but so is any sort of deduplication in any system, but you do this to avoid bugs down the line. **Arun Sori** (14:28): > I am sure we can do a better job here but IMO we hardly looked at what should be the correct way to do the ownership model but just following existing patterns. Particularly in the rush to have things deployed within 1 week **Bohdan Parkhomchuk** (14:30): > @bgreene Thank you. This is definitely something very new? I was under impression that if I did something not in the best way this would be corrected by a reviewing SRE. > > The reason for "duplicating code" is simple: in offsite we agreed to rebuild environment and GKE cluster, which involved copying of the code. So the initial copied code also was not in the best shape. **Andrew Newdigate** (14:31): > @Arun Sori Sure, but if we just keep with the old way of doing things, which everyone agrees is broken, and is leading to major leadtimes for infrastructure deployments, and never commit to improving the process, how will things ever improve? **Arun Sori** (14:32): > @andrew I 100% agree. We are definitely trying to do a better job here with our helm charts to not become too .com focused but our infra things can be better **Bohdan Parkhomchuk** (14:34): > I also saw that we don't use the GitLab GKE module and use the one from community. Which is not the proper way to build GKE? Switching to this is not a trivial code transfer with some values tweaks. **Andrew Newdigate** (14:35): > @Bohdan I'm much less concerned about that. That's a two way door decision which we can change later </details> <!--AI-Sessions dir: ~/.claude/projects/-Users-angelo-rivera/ 2cf4ce7a-7829-4b37-8a9e-2a6baa9b7880.jsonl (2026-04-10)-->