### Problem to solve Systems administrators have no way of enabling a maintenance / read-only for Gitlab. This is useful in a few different scenarios: - During a planned failover from a primary to a secondary, systems administrators need to take GitLab out of the loadbalancers or use another method to block access to a running gitlab installation. This allows the state between the primary and secondary to be fully synced. Having a maintenance mode that renders GitLab *read-only* would help here. - On a secondary node in case of an unavailable primary it is currently not possible to login without the primary being available. It would be desirable in a disaster recovery situation or if replication is broken for another reason to allow a secondary to be put into a "maintenance mode" that is functional without any reliance on the primary. **Note**: This is not going to be addressed in the first iteration. We are currently not focusing on the following use case: - It would allow systems administrators to verify or validate that everything works well post-upgrade before opening up an instance to the masses. We currently have the deploy page but this does not allow admins to access GitLab for this purpose. ### Intended users * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) ### Further details We already support a static deploy page via `gitlab-ctl deploy-page up` that blocks UI access but you can still push to repositories. We also recommend the following procedure during a planned failover: https://docs.gitlab.com/ee/administration/geo/disaster_recovery/planned_failover.html#prevent-updates-to-the-primary-node But users are largely on their own. Mural: https://app.mural.co/t/gitlab2474/m/gitlab2474/1581081252456/2893a6a06811a73bfd9ed6dd6a76aa257e970a31 ### Proposal I believe we can deliver several iterations to create the maintenance mode, which should be defined more closely in follow up issues: 1. Create a POC that establishes if we can use the existing Geo middleware to facilitate a GitLab read-only mode. See https://gitlab.com/gitlab-org/gitlab/issues/36211 --> DONE 1. Create a maintenance mode MVC that builds on the POC. Allow admin users to login into GitLab in maintenance mode, modify maintenance setting via the admin area. A simple on/off toggle for example. Regular users should be able-to use Gitlab in read-only mode. 1. Add scheduling for maintenance mode 1. On the secondary (which is already read-only) enable a maintenance mode that allows logins while the primary is unavailable. ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. --> We need to create new documentation for this to describe the behaviour in all these modes. ### Testing Please refer to the [test planning issue](https://gitlab.com/gitlab-org/gitlab/-/issues/266992). ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> 1. A Primary can be put temporarily into a *read only* mode that does not allow for any changes to occur. This is already useful for a planned failover to a secondary 2. Admins can login to the primary during read only mode to validate concerns or other issues 3. The secondary also supports a maintenance mode that allows admins to login while the primary is unavailable ### What is the type of buyer? <!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> * Starter - I think admins expect this feature by now * Premium (for geo related issues) We plan to ship this at the ~"GitLab Premium" tier. ### Links / references https://gitlab.zendesk.com/agent/tickets/137012 https://gitlab.zendesk.com/agent/tickets/131722 https://gitlab.zendesk.com/agent/tickets/113397 https://gitlab.zendesk.com/agent/tickets/103702 https://gitlab.zendesk.com/agent/tickets/100289 https://gitlab.my.salesforce.com/0016100001GOt4Y?srPos=0&srKp=001