## :sparkles: Summary We will migrate canonical for `config-mgmt` to GitLab.com to reduce barriers for GitLab team members outside the Infrastructure department to contribute infrastructure changes, relying on Infrastructure maintainer reviews and policies to enforce best practices. ## :mag: Problem Statement GitLab team members outside of infrastructure face significant barriers when contributing to `config-mgmt` or making infrastructure changes. These barriers create bottlenecks that limit our ability to scale infrastructure contributions across teams. ## :books: Background ### Current Access Challenges * **Platform Barrier:** `config-mgmt` is hosted on `ops.gitlab.net` requiring team members to log into a separate instance. * **Permission Gap:** Most team members lack default Developer permissions, requiring either: * Adhoc Access Requests (AR) submissions * Requesting infrastructure team members to make changes on their behalf. This dependency model doesn't scale effectively, and positions infrastructure as an unintended bottleneck for cross-team collaboration, particularly as we try to move to a model where we are enabling GitLab team members outside of Infrastructure to contribute. <details> <summary> **Why is ops the source of truth for this repo, and not others?** </summary> In 2018 there was a plan to move operations from GitLab.com to Ops: https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/5159 * config-mgmt - https://ops.gitlab.net/gitlab-com/gl-infra/config-mgmt * chef-repo - https://gitlab.com/gitlab-com/gl-infra/chef-repo * chef-cookbooks: https://gitlab.com/gitlab-cookbooks * k8s-workloads: https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/gitlab-com * Helm charts: https://gitlab.com/gitlab-com/gl-infra/charts Looking at https://ops.gitlab.net/gitlab-com/gl-infra it seems the majority of our configuration is actually managed on `.com` and mirrored to ops. `config-mgmt` is currently the outlier. </details> <details> <summary> **Does this go against the Component Ownership Model?** </summary> No. While the ultimate goal is that we shift infrastructure ownership left, the reality is that `config-mgmt` which is the source of truth for much of our infrastructure today is going to be maintained for a long time. Enabling contributions to this repository outside of the Infrastructure department will reduce friction experienced by GitLab team members. Related Handbook MR: https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/14787 </details> ### Examples DNS Configuration: Engineers raising requests that should be capable of self-serving: * https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/27098+ * https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/26980+ * https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/25833+ ## :rocket: Approach Migrate `config-mgmt` to GitLab.com. Considerations: * Ensure auditable processes are maintained. * Ensure Atlantis is configured appropriately. * Ensure MR history is retained. * Ensure only infrastructure can apply changes. * Policies put in place to prevent any unexpected changes to infrastrcture. * Ensure processes are in place for seamless disaster recovery. * Notify team members to update their remotes. ## :dart: Exit Criteria * [ ] Audibility is maintained for critical infrastructure components. * [ ] The canonical repository for `config-mgmt` is managed on GitLab.com. * [ ] Policies are in place to enforce infrastructure best practices. * [ ] A process is in place (and exercised) for contributing to the mirror in case of emergency. * [ ] Notifications are configured to reduce friction for reviewing pipeline output. ## DRI TODO ### Participants TODO ## Issue admin ``` /epic https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1647 /label ~"group::Foundations" ~"workflow-infra::Triage" ~"Foundations::Project work" ``` <!--STATUS NOTE START--> <!--STATUS NOTE END-->