Document Gitlab::Middleware::Readonly

doc/development/geo.md

@@ -78,19 +78,20 @@ to see if there are changes since the last time the log was checked
 and will handle repository updates, deletes, changes & renames.
 
 
-## Readonly
+## Read-only
 
 All **Secondary** nodes are read-only.
 
-We have a Rails Middleware that filters any potentially writing operations
-and prevent user from trying to update the database and getting a 500 error
-(see `Gitlab::Middleware::Readonly`).
+The general principle of a [read-only database](verifying_database_capabilities.md#read-only-database)
+applies to all Geo secondary nodes. So `Gitlab::Database.read_only?`
+will always return `true` on a secondary node.
 
-Database will already be read-only in a replicated setup, so we don't need to
-take any extra step for that.
+When some write actions are not allowed, because the node is a
+secondary, consider the `Gitlab::Database.read_only?` or `Gitlab::Database.read_write?`
+guard, instead of `Gitlab::Geo.secondary?`.
 
-We do use our feature toggle `Gitlab::Database.read_only?` to deny write operations
-on a node that is in read-only mode. This toggle is also available in CE.
+Database itself will already be read-only in a replicated setup, so we
+don't need to take any extra step for that.
 
 ## File Transfers
 

doc/development/verifying_database_capabilities.md

@@ -24,3 +24,15 @@ else
   run_query
 end
 ```
+
+# Read-only database
+
+The database can be used in read-only mode. In this case we have to
+make sure all GET requests don't attempt any write operations to the
+database. If one of those requests wants to write to the database, it needs
+to be wrapped in a `Gitlab::Database.read_only?` or `Gitlab::Database.read_write?`
+guard, to make sure it doesn't for read-only databases.
+
+We have a Rails Middleware that filters any potentially writing
+operations (the CUD operations of CRUD) and prevent the user from trying
+to update the database and getting a 500 error (see `Gitlab::Middleware::ReadOnly`).