Merge branch 'nhxnguyen-master-patch-18286' into 'master'

Update Disaster Recovery direction page

See merge request !83118

data/categories.yml

@@ -1934,7 +1934,7 @@ disaster_recovery:
   roi: false
   available: 2018-01-01
   viable: 2021-02-22
-  complete: 2021-07-22
+  complete: 2021-10-22
   lovable: 2023-12-22
   maturity: viable
   marketing: true

source/direction/geo/disaster_recovery/index.html.md.erb

@@ -10,7 +10,7 @@ canonical_path: "/direction/geo/disaster_recovery/"
 ## 🚨 Disaster Recovery
-**Last updated**: 2021-03-11
+**Last updated**: 2021-06-01
 ### Introduction and how you can help
@@ -26,7 +26,7 @@ GitLab installations hold business critical information and data. The Disaster
 Recovery (DR) category helps our customers fulfill their business continuity
 plans by creating processes that allow the recovery of a GitLab instance following a
 natural or human-caused disaster. DR complements GitLab's [Reference Architectures](https://about.gitlab.com/solutions/reference-architectures/) and
-utilizes [Geo sites](https://docs.gitlab.com/ee/administration/geo/index.html
+utilizes [Geo sites](https://docs.gitlab.com/ee/administration/geo/index.html)
 to enable a failover in a disaster situation. We want DR to be
 robust, complete and easy to use for [systems
 administrators](https://about.gitlab.com/handbook/marketing/strategic-marketing/roles-personas/#sidney-systems-administrator) - especially in a potentially stressful recovery situation.
@@ -101,6 +101,8 @@ We envision that GitLab's Disaster Recovery processes and solution should
 - 😁 **Complete** - Configuration is
   simple and all solutions are constantly monitored. A dashboard informs users
   of the current data replication and verification status. A recovery process is less than <10 steps.
+- 😁 **Complete** - All Git and File data is replicated and verified. A dashboard informs users
+  of the current data replication and verification status. A recovery process is less than <10 steps.
 - 😍 **Lovable** - Automatic failovers are supported.
 For more information on how we use personas and roles at GitLab, please
@@ -113,7 +115,7 @@ the [Disaster Recovery Complete maturity epic](https://gitlab.com/groups/gitlab-
 #### Improved data verification
-As of March 2021, [Geo replicates ~83% of all
+As of March 2021, [Geo replicates ~86% and verifies ~48% of all
 data](https://docs.gitlab.com/ee/administration/geo/replication/datatypes.html#limitations-on-replicationverification);
 however, not all data is automatically verified. We've created a [self-service
 framework](https://docs.gitlab.com/ee/development/geo/framework.html) that
@@ -138,6 +140,17 @@ generally available](https://gitlab.com/groups/gitlab-org/-/epics/2536).
 We've worked with systems administrators and are going to [design and implement
 a new Geo overview page](https://gitlab.com/groups/gitlab-org/-/epics/4712).
+#### Simplifying Promotion of Secondary Nodes
+
+It is currently possible to promote a secondary node to a primary node, either
+during a planned failover or in a genuine disaster recovery situation. Geo
+supports promotion for a single node installation and for an HA configuration.
+The current promotion process is consists of a large number of manual preflight
+checks, followed by the actual promotion. The promotion is only possible in the
+command line, no UI flow is possible and for high-availability configurations
+modifications to the gitlab.rb file are required on almost all nodes. Given the
+critical nature of this process, Geo should make it simple to promote a secondary,
+especially for more complex high-availability configurations.
 #### Migrating existing datatypes to the Self Service Framework