Merge branch 'rename-geo-nodes-nav-item' into 'master'

Rename Admin Area "Geo Nodes" nav item to "Geo"

Closes #7712

See merge request gitlab-org/gitlab-ee!7466

app/views/layouts/nav/sidebar/_admin.html.haml

@@ -175,13 +175,13 @@
           .nav-icon-container
             = sprite_icon('location-dot')
           %span.nav-item-name
-            #{ _('Geo Nodes') }
+            #{ _('Geo') }
         - if Gitlab::Geo.secondary?
           %ul.sidebar-sub-level-items
             = nav_link(controller: 'admin/geo/nodes', html_options: { class: "fly-out-top-item" } ) do
               = link_to admin_geo_nodes_path do
                 %strong.fly-out-top-item-name
-                  #{ _('Geo Nodes') }
+                  #{ _('Geo') }
             %li.divider.fly-out-top-item
             = nav_link(path: 'admin/geo/nodes#index') do
               = link_to admin_geo_nodes_path, title: 'Nodes' do

doc/administration/geo/disaster_recovery/background_verification.md

@@ -63,14 +63,14 @@ feature flag on each **secondary**, to do this run
 
 # Repository verification
 
-Visit the **Admin Area ➔ Geo nodes** dashboard on the **primary** and expand
+Navigate 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
 in grey, and failures in red.
 
 ![Verification status](img/verification-status-primary.png)
 
-Visit the **Admin Area ➔ Geo nodes** dashboard on the **secondary** and expand
+Navigate to the **Admin Area > Geo** dashboard on the **secondary** node and expand
 the **Verification information** tab for that node to view automatic verifcation
 status for repositories and wikis. As with checksumming, successes are shown in
 green, pending work in grey, and failures in red.

doc/administration/geo/disaster_recovery/planned_failover.md

@@ -101,7 +101,7 @@ The maintenance window won't end until Geo replication and verification is
 completely finished. To keep the window as short as possible, you should
 ensure these processes are close to 100% as possible during active use.
 
-Visit the **Admin Area ➔ Geo nodes** dashboard on the **secondary** node to
+Navigate to the **Admin Area > Geo** dashboard on the **secondary** node to
 review status. Replicated objects (shown in green) should be close to 100%,
 and there should be no failures (shown in red). If a large proportion of
 objects aren't yet replicated (shown in grey), consider giving the node more
@@ -126,8 +126,8 @@ This [content was moved to another location][background-verification].
 
 ### Notify users of scheduled maintenance
 
-On the **primary**, navigate to **Admin Area ➔ Messages**, add a broadcast
-message. You can check under **Admin Area ➔ Geo Nodes** to estimate how long it
+On the **primary** node, navigate to **Admin Area > Messages**, add a broadcast
+message. You can check under **Admin Area > Geo** to estimate how long it
 will take to finish syncing. An example message would be:
 
 > A scheduled maintenance will take place at XX:XX UTC. We expect it to take
@@ -136,7 +136,7 @@ will take to finish syncing. An example message would be:
 ## Prevent updates to the **primary**
 
 Until a [read-only mode][ce-19739] is implemented, updates must be prevented
-from happening manually. Note that your **secondary** still needs read-only
+from happening manually. Note that your **secondary** node still needs read-only
 access to the primary for the duration of the maintenance window.
 
 1. At the scheduled time, using your cloud provider or your node's firewall, block
@@ -174,7 +174,7 @@ access to the primary for the duration of the maintenance window.
    connection.
 
 1. Disable non-Geo periodic background jobs on the primary node by navigating
-   to **Admin Area ➔ Monitoring ➔ Background Jobs ➔ Cron** , pressing `Disable All`,
+   to **Admin Area > Monitoring > Background Jobs > Cron** , pressing `Disable All`,
    and then pressing `Enable` for the `geo_sidekiq_cron_config_worker` cron job.
    This job will re-enable several other cron jobs that are essential for planned
    failover to complete successfully.
@@ -183,20 +183,20 @@ access to the primary for the duration of the maintenance window.
 
 1. If you are manually replicating any data not managed by Geo, trigger the
    final replication process now.
-1. On the **primary**, navigate to **Admin Area ➔ Monitoring ➔ Background Jobs ➔ Queues**
+1. On the **primary** node, navigate to **Admin Area > Monitoring > Background Jobs > Queues**
    and wait for all queues except those with `geo` in the name to drop to 0.
    These queues contain work that has been submitted by your users; failing over
    before it is completed will cause the work to be lost!
-1. On the **primary**, navigate to **Admin Area ➔ Geo Nodes** and wait for the
-   following conditions to be true of the **secondary** you are failing over to:
+1. On the **primary** node, navigate to **Admin Area > Geo** and wait for the
+   following conditions to be true of the **secondary** node you are failing over to:
     * All replication meters to each 100% replicated, 0% failures
     * All verification meters reach 100% verified, 0% failures
     * Database replication lag is 0ms
     * The Geo log cursor is up to date (0 events behind)
 
-1. On the **secondary**, navigate to **Admin Area > Monitoring ➔ Background Jobs ➔ Queues**
+1. On the **secondary** node, navigate to **Admin Area > Monitoring > Background Jobs > Queues**
    and wait for all the `geo` queues to drop to 0 queued and 0 running jobs.
-1. On the **secondary**, use [these instructions][foreground-verification]
+1. On the **secondary** node, use [these instructions][foreground-verification]
    to verify the integrity of CI artifacts, LFS objects and uploads in file
    storage.
 

doc/administration/geo/replication/configuration.md

@@ -170,7 +170,7 @@ keys must be manually replicated to the secondary node.
 
 ### Step 3. Add the secondary GitLab node
 
-1. Visit the **primary** node's **Admin Area ➔ Geo Nodes**
+1. Visit the **primary** node's **Admin Area > Geo**
    (`/admin/geo_nodes`) in your browser.
 1. Add the secondary node by providing its full URL. **Do NOT** check the box
    'This is a primary node'.
@@ -215,7 +215,7 @@ infrastructure issue [gitlab-com/infrastructure#2821].
 Using hashed storage significantly improves Geo replication - project and group
 renames no longer require synchronization between nodes.
 
-1. Visit the **primary** node's **Admin Area ➔ Settings**
+1. Visit the **primary** node's **Admin Area > Settings**
    (`/admin/application_settings`) in your browser
 1. In the `Repository Storages` section, check `Create new projects using hashed storage paths`:
 
@@ -234,7 +234,7 @@ on the secondary.
 ### Step 6. Enable Git access over HTTP/HTTPS
 
 Geo synchronizes repositories over HTTP/HTTPS, and therefore requires this clone
-method to be enabled. Navigate to **Admin Area ➔ Settings**
+method to be enabled. Navigate to **Admin Area > Settings**
 (`/admin/application_settings`) on the primary node, and set
 `Enabled Git access protocols` to `Both SSH and HTTP(S)` or `Only HTTP(S)`.
 
@@ -243,7 +243,7 @@ method to be enabled. Navigate to **Admin Area ➔ Settings**
 Congratulations! Your secondary geo node is now configured!
 
 You can login to the secondary node with the same credentials you used on the
-primary. Visit the secondary node's **Admin Area ➔ Geo Nodes**
+primary. Visit the secondary node's **Admin Area > Geo**
 (`/admin/geo_nodes`) in your browser to check if it's correctly identified as a
 secondary Geo node and if Geo is enabled.
 
@@ -259,7 +259,7 @@ If your installation isn't working properly, check the
 The two most obvious issues that can become apparent in the dashboard are:
 
 1. Database replication not working well
-1. Instance to instance notification not working. In that case, it can be
+2. Instance to instance notification not working. In that case, it can be
    something of the following:
      - You are using a custom certificate or custom CA (see the
        [troubleshooting document])

doc/administration/geo/replication/configuration_source.md

@@ -24,7 +24,7 @@ NOTE: **Notes:**
 - **Do not** setup any custom authentication in the secondary nodes, this will be
   handled by the primary node.
 - **Do not** add anything in the secondaries Geo nodes admin area
-  (**Admin Area ➔ Geo Nodes**). This is handled solely by the primary node.
+  (**Admin Area > Geo**). This is handled solely by the primary node.
 
 ### Step 1. Manually replicate secret GitLab values
 
@@ -90,7 +90,7 @@ Read [Manually replicate primary SSH host keys][configuration-replicate-ssh]
 
 ### Step 3. Add the secondary GitLab node
 
-1. Visit the **primary** node's **Admin Area ➔ Geo Nodes**
+1. Navigate to the **primary** node's **Admin Area > Geo**
    (`/admin/geo_nodes`) in your browser.
 1. Add the secondary node by providing its full URL. **Do NOT** check the box
    'This is a primary node'.
@@ -148,7 +148,7 @@ update-ca-certificates
 ### Step 6. Enable Git access over HTTP/HTTPS
 
 Geo synchronizes repositories over HTTP/HTTPS, and therefore requires this clone
-method to be enabled. Navigate to **Admin Area ➔ Settings**
+method to be enabled. Navigate to **Admin Area > Settings**
 (`/admin/application_settings`) on the primary node, and set
 `Enabled Git access protocols` to `Both SSH and HTTP(S)` or `Only HTTP(S)`.
 

doc/administration/geo/replication/troubleshooting.md

@@ -11,7 +11,7 @@ what you need to fix (all commands and path locations are for Omnibus installs):
 
 #### First check the health of the secondary
 
-Visit the primary node's **Admin Area ➔ Geo Nodes** (`/admin/geo_nodes`) in
+Visit the primary node's **Admin Area > Geo** (`/admin/geo_nodes`) in
 your browser. We perform the following health checks on each secondary node
 to help identify if something is wrong:
 
@@ -76,7 +76,7 @@ process](database.md) on the secondary.
 
 #### How do I fix the message, "Command exceeded allowed execution time" when setting up replication?
 
-This may happen while [initiating the replication process][database-start-replication] on the Geo secondary, 
+This may happen while [initiating the replication process][database-start-replication] on the Geo secondary,
 and indicates that your initial dataset is too large to be replicated in the default timeout (30 minutes).
 
 Re-run `gitlab-ctl replicate-geo-database`, but include a larger value for
@@ -91,7 +91,7 @@ the default thirty minutes. Adjust as required for your installation.
 
 #### How do I fix the message, "PANIC: could not write to file 'pg_xlog/xlogtemp.123': No space left on device"
 
-Determine if you have any unused replication slots in the primary database.  This can cause large amounts of 
+Determine if you have any unused replication slots in the primary database.  This can cause large amounts of
 log data to build up in `pg_xlog`. Removing the unused slots can reduce the amount of space used in the `pg_xlog`.
 
 1. Start a PostgreSQL console session:
@@ -100,7 +100,7 @@ log data to build up in `pg_xlog`. Removing the unused slots can reduce the amou
     sudo gitlab-psql gitlabhq_production
     ```
 
-    > Note that using `gitlab-rails dbconsole` will not work, because managing replication slots requires 
+    > Note that using `gitlab-rails dbconsole` will not work, because managing replication slots requires
       superuser permissions.
 
 2. View your replication slots with
@@ -114,7 +114,7 @@ Slots where `active` is `f` are not active.
 - When this slot should be active, because you have a secondary configured using that slot,
   log in to that secondary and check the PostgreSQL logs why the replication is not running.
 
-- If you are no longer using the slot (e.g. you no longer have Geo enabled), you can remove it with in the 
+- If you are no longer using the slot (e.g. you no longer have Geo enabled), you can remove it with in the
   PostgreSQL console session:
 
     ```sql
@@ -151,21 +151,21 @@ to start again from scratch, there are a few steps that can help you:
 
     It's possible to make Sidekiq stop gracefully, but making it stop getting new jobs and
     wait until the current jobs to finish processing.
-    
+
     You need to send a **SIGTSTP** kill signal for the first phase and them a **SIGTERM**
     when all jobs have finished. Otherwise just use the `gitlab-ctl stop` commands.
-    
+
     ```bash
     gitlab-ctl status sidekiq
     # run: sidekiq: (pid 10180) <- this is the PID you will use
     kill -TSTP 10180 # change to the correct PID
-    
+
     gitlab-ctl stop sidekiq
     gitlab-ctl stop geo-logcursor
     ```
-    
+
     You can watch sidekiq logs to know when sidekiq jobs processing have finished:
-    
+
     ```bash
     gitlab-ctl tail sidekiq
     ```
@@ -177,39 +177,39 @@ to start again from scratch, there are a few steps that can help you:
     mkdir -p /var/opt/gitlab/git-data/repositories
     chown git:git /var/opt/gitlab/git-data/repositories
     ```
-    
+
     TIP: **Tip**
     You may want to remove the `/var/opt/gitlab/git-data/repositories.old` in the future
     as soon as you confirmed that you don't need it anymore, to save disk space.
-    
+
 1. _(Optional)_ Rename other data folders and create new ones
 
     CAUTION: **Caution**:
-    You may still have files on the secondary that have been removed from primary but 
+    You may still have files on the secondary that have been removed from primary but
     removal have not been reflected. If you skip this step, they will never be removed
     from this Geo node.
-    
+
     Any uploaded content like file attachments, avatars or LFS objects are stored in a
     subfolder in one of the two paths below:
-    
+
     1. /var/opt/gitlab/gitlab-rails/shared
     1. /var/opt/gitlab/gitlab-rails/uploads
-    
+
     To rename all of them:
-    
+
     ```bash
     gitlab-ctl stop
- 
+
     mv /var/opt/gitlab/gitlab-rails/shared /var/opt/gitlab/gitlab-rails/shared.old
     mkdir -p /var/opt/gitlab/gitlab-rails/shared
- 
+
     mv /var/opt/gitlab/gitlab-rails/uploads /var/opt/gitlab/gitlab-rails/uploads.old
     mkdir -p /var/opt/gitlab/gitlab-rails/uploads
     ```
-    
+
     Reconfigure in order to recreate the folders and make sure permissions and ownership
     are correctly
-    
+
     ```bash
     gitlab-ctl reconfigure
     ```

doc/administration/geo/replication/updating_the_geo_nodes.md

@@ -159,7 +159,7 @@ Replicating over SSH has been deprecated, and support for this option will be
 removed in a future release.
 
 To switch to HTTP/HTTPS replication, log into the primary node as an admin and visit
-**Admin Area ➔ Geo Nodes** (`/admin/geo_nodes`). For each secondary listed,
+**Admin Area > Geo** (`/admin/geo_nodes`). For each secondary listed,
 press the "Edit" button, change the "Repository cloning" setting from
 "SSH (deprecated)" to "HTTP/HTTPS", and press "Save changes". This should take
 effect immediately.

doc/user/admin_area/geo_nodes.md

@@ -3,7 +3,7 @@
 For more information about setting up GitLab Geo, read the
 [Geo documentation](../../gitlab-geo/README.md).
 
-When you're done, you can navigate to **Admin area ➔ Geo nodes** (`/admin/geo_nodes`).
+When you're done, you can navigate to **Admin area > Geo** (`/admin/geo_nodes`).
 
 ## Common settings
 

ee/changelogs/unreleased/rename-geo-nodes-nav-item.yml

+---
+title: Rename Admin Area Geo Nodes nav item to Geo
+merge_request: 7466
+author:
+type: other

qa/qa/ee/page/menu/admin.rb

@@ -7,13 +7,13 @@ module QA
             page.module_eval do
               view 'app/views/layouts/nav/sidebar/_admin.html.haml' do
                 element :license, "_('License')"
-                element :geo_node, "_('Geo Nodes')"
+                element :geo_node, "_('Geo')"
               end
             end
           end
 
           def go_to_geo_nodes
-            click_link 'Geo Nodes'
+            click_link 'Geo'
           end
 
           def go_to_license