Merge branch 'sunjungp-master-patch-82122' into 'master'

Update Geo UI screenshots in docs page

See merge request gitlab-org/gitlab!64080

doc/administration/geo/disaster_recovery/background_verification.md

@@ -59,18 +59,18 @@ Feature.enable('geo_repository_verification')
 ## Repository verification
 
 Go to the **Admin Area > Geo** dashboard on the **primary** node and expand
-the **Verification information** tab for that node to view automatic checksumming
-status for repositories and wikis. Successes are shown in green, pending work
+the **Verification information** section for that node to view automatic checksumming
+status for each data type. Successes are shown in green, pending work
 in gray, and failures in red.
 
-![Verification status](img/verification-status-primary.png)
+![Verification status](img/verification_status_primary_v14_0.png)
 
 Go to the **Admin Area > Geo** dashboard on the **secondary** node and expand
-the **Verification information** tab for that node to view automatic verification
-status for repositories and wikis. As with checksumming, successes are shown in
+the **Verification information** section for that node to view automatic verification
+status for each data type. As with checksumming, successes are shown in
 green, pending work in gray, and failures in red.
 
-![Verification status](img/verification-status-secondary.png)
+![Verification status](img/verification_status_secondary_v14_0.png)
 
 ## Using checksums to compare Geo nodes
 

doc/administration/geo/disaster_recovery/planned_failover.md

@@ -115,7 +115,7 @@ and there should be no failures (shown in red). If a large proportion of
 objects aren't yet replicated (shown in gray), consider giving the node more
 time to complete
 
-![Replication status](img/replication-status.png)
+![Replication status](../replication/img/geo_node_dashboard_v14_0.png)
 
 If any objects are failing to replicate, this should be investigated before
 scheduling the maintenance window. Following a planned failover, anything that

doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md

@@ -69,7 +69,7 @@ and there should be no failures (shown in red). If a large proportion of
 objects aren't yet replicated (shown in gray), consider giving the node more
 time to complete.
 
-![Replication status](../img/replication-status.png)
+![Replication status](../../replication/img/geo_node_dashboard_v14_0.png)
 
 If any objects are failing to replicate, this should be investigated before
 scheduling the maintenance window. After a planned failover, anything that

doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md

@@ -57,7 +57,7 @@ and there should be no failures (shown in red). If a large proportion of
 objects aren't yet replicated (shown in gray), consider giving the node more
 time to complete.
 
-![Replication status](../img/replication-status.png)
+![Replication status](../../replication/img/geo_node_dashboard_v14_0.png)
 
 If any objects are failing to replicate, this should be investigated before
 scheduling the maintenance window. After a planned failover, anything that

doc/administration/geo/replication/configuration.md

@@ -269,7 +269,7 @@ The initial replication, or 'backfill', is probably still in progress. You
 can monitor the synchronization process on each Geo node from the **primary**
 node's **Geo Nodes** dashboard in your browser.
 
-![Geo dashboard](img/geo_node_dashboard.png)
+![Geo dashboard](img/geo_node_dashboard_v14_0.png)
 
 If your installation isn't working properly, check the
 [troubleshooting document](troubleshooting.md).

doc/administration/geo/replication/troubleshooting.md

@@ -35,7 +35,7 @@ to help identify if something is wrong:
 - Is the node's secondary tracking database connected?
 - Is the node's secondary tracking database up-to-date?
 
-![Geo health check](img/geo_node_dashboard.png)
+![Geo health check](img/geo_node_health_v14_0.png)
 
 For information on how to resolve common errors reported from the UI, see
 [Fixing Common Errors](#fixing-common-errors).