From 24eb9af833ea925daecff4f9d63f5e5c99a89389 2023-12-28 09:12:47
From: RhodeCode Admin <admin@rhodecode.com>
Date: 2023-12-28 09:12:47
Subject: [PATCH] docs(upgrade): explain how to avoid scale 2x on upgrade

---

diff --git a/docs/source/install/upgrade.rst b/docs/source/install/upgrade.rst
index 66e1499..d4fb954 100644
--- a/docs/source/install/upgrade.rst
+++ b/docs/source/install/upgrade.rst
@@ -21,21 +21,50 @@ Then upgrade each stack based on instructions provided from the help output:
 .. note::
 
     ./rcstack stack-upgrade rhodecode is a 0 downtime upgrade procedure.
-    This will spawn 2x more nodes to perform the upgrade and then remove the old instances. This way all incoming traffic
-    will be handled continuously without any interruptions on upgrade
+    This will spawn 2x more nodes to perform the upgrade and then remove the old instances.
+    This way all incoming traffic will be handled continuously without any interruptions on upgrade
+
+
+Example for full upgrade procedure:
+
+
+.. code-block:: bash
+
+    ./rcstack self-update
+    ./rcstack stack-upgrade router
+    ./rcstack stack-upgrade services
+    ./rcstack stack-upgrade rhodecode
+    ./rcstack stack-upgrade metrics
+
+
+.. note::
+
+    ./rcstack stack-upgrade does scaling of services which might use more RAM to handle the double instance amount.
+    To avoid that stop each stack before running stack upgrade. This way services get upgraded without 2x scaling.
+    This method however would cause a downtime.
+
+    .. code-block:: bash
+
+        ./rcstack self-update
+        ./rcstack stack router down && ./rcstack stack-upgrade router
+        ./rcstack stack services down && ./rcstack stack-upgrade services
+        ./rcstack stack rhodecode down && ./rcstack stack-upgrade rhodecode
+        ./rcstack stack metrics down && ./rcstack stack-upgrade metrics
+
 
 The above upgrade uses default timeouts to wait for any currently ongoing traffic to stop to kill the workers.
 There are two additional flags that can be used for a faster upgrade that could let to end users errors, or small downtime
 but will enforce the upgrade to be performed as fast as possible.
 
 
-Fast upgrade with max 30s wait time after new upgraded containers start, and wait 5s before force killing old
-containers
+Fast upgrade with max 65s wait time after new upgraded containers start, and wait 5s before force killing old
+containers. This is still 0 downtime upgrade, but stoping existing containers is forced to 5s
+which might result in killed ongoing connections
 
 
 .. code-block:: bash
 
-    ./rcstack stack-upgrade rhodecode --stop-wait 30 --docker-stop-wait 5
+    ./rcstack stack-upgrade rhodecode --stop-wait 65 --docker-stop-wait 5