Update broadcast message notes for Geo

doc/administration/geo/replication/index.md

@@ -189,7 +189,7 @@ When you have object storage enabled, please consult the
 
 ## Disaster Recovery
 
-Read through the [Disaster Recovery documentation][disaster-recovery] how to use Geo to mitigate data-loss and 
+Read through the [Disaster Recovery documentation][disaster-recovery] how to use Geo to mitigate data-loss and
 restore services in a disaster scenario.
 
 ### Replicating the Container Registry
@@ -198,15 +198,14 @@ Read how to [replicate the Container Registry][docker-registry].
 
 ## Current limitations
 
-> **IMPORTANT**: This list of limitations tracks only the latest version. If you are in an older version, 
-extra limitations may be in place. 
+> **IMPORTANT**: This list of limitations tracks only the latest version. If you are in an older version,
+extra limitations may be in place.
 
 - You cannot push code to secondary nodes, see [gitlab-org/gitlab-ee#3912] for details.
 - The primary node has to be online for OAuth login to happen (existing sessions and Git are not affected)
-- The installation takes multiple manual steps that together can take about an hour depending on circumstances; we are 
+- The installation takes multiple manual steps that together can take about an hour depending on circumstances; we are
   working on improving this experience, see [gitlab-org/omnibus-gitlab#2978] for details.
 - Real-time updates of issues/merge requests (e.g. via long polling) doesn't work on the secondary
-- Broadcast messages set on the primary won't be seen on the secondary without a cache flush (e.g. gitlab-rake cache:clear)
 - [Selective synchronization](configuration.md#selective-synchronization)
   applies only to files and repositories. Other datasets are replicated to the
   secondary in full, making it inappropriate for use as an access control

doc/administration/geo/replication/updating_the_geo_nodes.md

@@ -14,6 +14,15 @@ all you need to do is update GitLab itself:
    the tracking database is enabled.
 1. [Test](#check-status-after-updating) primary and secondary nodes, and check version in each.
 
+## Upgrading to GitLab 10.8
+
+Before 10.8, broadcast messages would not propagate without flushing the cache on the secondaries.
+This has been fixed in 10.8, but requires one last cache flush on each secondary node:
+
+```bash
+gitlab-rake cache:clear
+```
+
 ## Upgrading to GitLab 10.6
 
 In 10.4 we started to recommend that you define a password for database user (`gitlab`).
@@ -30,19 +39,19 @@ authentication method.
     # Confirm password: mypassword
     # fca0b89a972d69f00eb3ec98a5838484
     ```
-    
+
     Copy the generated hash and edit `/etc/gitlab/gitlab.rb`:
-    
+
     ```ruby
     # Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab`
     postgresql['sql_user_password'] = 'fca0b89a972d69f00eb3ec98a5838484'
-    
+
     # If you have HA setup, this must be present in all nodes as well
     gitlab_rails['db_password'] = 'mypassword'
     ```
-    
+
     Still in the configuration file, locate and remove the `trust_auth_cidr_address`:
-    
+
     ```ruby
     postgresql['trust_auth_cidr_addresses'] = ['127.0.0.1/32','1.2.3.4/32'] # <- Remove this
     ```
@@ -59,7 +68,7 @@ authentication method.
     ```ruby
     # Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab`
     postgresql['sql_user_password'] = 'fca0b89a972d69f00eb3ec98a5838484'
-    
+
     # If you have HA setup, this must be present in all nodes as well
     gitlab_rails['db_password'] = 'mypassword'
 
@@ -70,9 +79,9 @@ authentication method.
     # - replace '5.6.7.8' with the secondary public or VPC address
     postgresql['md5_auth_cidr_addresses'] = ['5.6.7.8/32']
     ```
-    
+
     Still in the configuration file, locate and remove the `trust_auth_cidr_address`:
-        
+
     ```ruby
     postgresql['trust_auth_cidr_addresses'] = ['127.0.0.1/32','5.6.7.8/32'] # <- Remove this
     ```
@@ -228,7 +237,7 @@ Omnibus is the following:
   1. Make sure you have Omnibus GitLab on the primary server
   1. Run `gitlab-ctl reconfigure` and `gitlab-ctl restart postgresql`. This will enable replication slots on the primary database.
   1. Check the steps about defining `postgresql['sql_user_password']`, `gitlab_rails['db_password']`
-  1. Make sure `postgresql['max_replication_slots']` matches the number of secondary Geo Nodes locations 
+  1. Make sure `postgresql['max_replication_slots']` matches the number of secondary Geo Nodes locations
   1. Install GitLab on the secondary server.
   1. Re-run the [database replication process][database-replication].