Review of USM Doc Updates

Final comments on the USM doc updates.
Add note.

Change-Id: I836f0672bf1b99494e1a21c730395ea9958ad5e7
Signed-off-by: Elisamara Aoki Gonçalves <elisamaraaoki.goncalves@windriver.com>

doc/source/_includes/upgrade-note.rest

@@ -0,0 +1,2 @@
+.. important-begin
+.. important-end

doc/source/updates/kubernetes/index-updates-kub-03d4d10fa0be.rst

@@ -2,6 +2,12 @@
 
 .. include:: /_includes/toc-title-updates-kub.rest
 
+.. only:: partner
+
+   .. include:: /_includes/upgrade-note.rest
+      :start-after: important-begin
+      :end-before: important-end
+
 .. only:: partner
 
    .. include:: /updates/index-updates-e3b970bb69ce.rst

doc/source/updates/kubernetes/introduction-platform-software-updates-upgrades-06d6de90bbd0.rst

@@ -70,10 +70,10 @@ Reboot-Required (RR)
    in this mode, the upversioning to a new Patch Release will result in a
    reboot of each host, as the host is upversioned to the new Patch Release.
 
-For a Major Release only, an **Abort and Rollback** of the active software
+For either a Patch Release or a Major Release, an **Abort and Rollback** of the
-deployment is supported.  The deployment of a Major Release can be aborted and
+active software deployment is supported.  The deployment of a Release can be
-rolled back at any step of the deployment process, as long as the active
+aborted and rolled back at any step of the deployment process, as long as the
-deployment has not been both completed and deleted.
+active deployment has not been both completed and deleted.
 
 For a Patch Release only, a **removal or un-deployment of a release** is
 supported. One or more Patch Releases can be removed/un-deployed by deploying a

doc/source/updates/kubernetes/manual-host-software-deployment-ee17ec6f71a4.rst

@@ -626,11 +626,6 @@ standard configuration.
 
 #. Delete the software deployment.
 
-   .. note::
-
-       If it is a system controller, the deployment should not be deleted
-       until the subclouds are up-to-date.
-
    .. note::
 
        For a major release deployment, after this command is executed, the
@@ -652,8 +647,15 @@ standard configuration.
     unavailable state, the alarm 900.024 ``Obsolete release in system`` is
     raised.
 
+.. rubric:: |postreq|
+
 #. Delete the old major release.
 
+   .. note::
+
+       If it is a System Controller, the deployment should not be deleted
+       until the subclouds are up-to-date.
+
    In the case of software deployment of a new major release, you should remove
    the old major release to reclaim disk space.
 

doc/source/updates/kubernetes/manual-rollback-host-software-deployment-9295ce1e6e29.rst

@@ -112,10 +112,10 @@ delete`.
                Host installation request sent to controller-0.
                Host installation was successful on controller-0
 
-            The host is still running the new software release, however boot
+           The host is still running the new software release, however boot
-            parameters have been updated to boot into the previous software
+           parameters have been updated to boot into the previous software
-            release on the next host reboot, which will occur in the next step
+           release on the next host reboot, which will occur in the next step
-            which unlocks the host.
+           which unlocks the host.
 
         #. Unlock controller-0.
 

doc/source/updates/kubernetes/orchestrated-deployment-host-software-deployment-d234754c7d20.rst

@@ -23,17 +23,19 @@ Software deployment Orchestration supports all standalone configurations:
 
 .. note::
 
-    Orchestrating the software deployment of a |DC| system is different from
+    Orchestrating the software deployment of subclouds in a |DC| system is
-    orchestrating the software deployment of standalone |prod| configurations.
+    different from orchestrating the software deployment of standalone |prod|
+    configurations. See
+    :ref:`distributed-upgrade-orchestration-process-using-the-cli`.
 
 Software deployment orchestration automatically iterates through all the hosts
 and deploys the new software load on each host: first the controller hosts,
 then the storage hosts, and lastly the worker hosts, and finally activates and
 completes the software deployment. During software deployment on a worker host
 (and duplex |AIO| controllers), pods or |VMs| are automatically moved to the
-alternate worker hosts. After software deployment orchestration has deployed
+alternate worker hosts, if a reboot of the host is required. After software
-the new software on all hosts, it will activate, complete, and delete the new
+deployment orchestration has deployed the new software on all hosts, it will
-software deployment.
+activate, complete, and delete the new software deployment.
 
 .. note::
 
@@ -327,9 +329,8 @@ to control and monitor their progress manually.
 
    ``wait-data-sync``
 
-   This waits for a period of time (up to many hours) and ensures that data
+   This waits for a period of time and ensures that data synchronization has
-   synchronization has completed after the upgrade of a controller or storage
+   completed after the upgrade of a controller or storage node.
-   node.
 
    .. code-block::
 
@@ -651,6 +652,11 @@ After a successful software deployment orchestration,
 
   - Remove the old major release to reclaim disk space.
 
+    .. note::
+
+         If this is a System Controller, the old major release should NOT be
+         deleted until all the subclouds have moved to new major release.
+
     .. code-block::
 
         ~(keystone_admin)]$ software list