starlingx/docs
Code Issues Proposed changes

Review of USM Doc Updates

Browse Source 
Final comments on the USM doc updates.
Add note.

Change-Id: I836f0672bf1b99494e1a21c730395ea9958ad5e7
Signed-off-by: Elisamara Aoki Gonçalves <elisamaraaoki.goncalves@windriver.com>
This commit is contained in:
Elisamara Aoki Gonçalves 2024-11-18 18:56:26 +00:00
parent d8ebebe083
commit aa5d940371
6 changed files with 37 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/source/_includes/upgrade-note.rest Normal file
View File

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

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

@ -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

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

@ -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
deployment is supported. The deployment of a Major Release can be aborted and
rolled back at any step of the deployment process, as long as the active
deployment has not been both completed and deleted.
For either a Patch Release or a Major Release, an **Abort and Rollback** of the
active software deployment is supported. The deployment of a Release can be
aborted and rolled back at any step of the deployment process, as long as the
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

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

@ -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.

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

@ -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
parameters have been updated to boot into the previous software
release on the next host reboot, which will occur in the next step
which unlocks the host.
The host is still running the new software release, however boot
parameters have been updated to boot into the previous software
release on the next host reboot, which will occur in the next step
which unlocks the host.
#. Unlock controller-0.

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

@ -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 standalone |prod| configurations.
Orchestrating the software deployment of subclouds in a |DC| system is
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
the new software on all hosts, it will activate, complete, and delete the new
software deployment.
alternate worker hosts, if a reboot of the host is required. After software
deployment orchestration has deployed the new software on all hosts, it will
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
synchronization has completed after the upgrade of a controller or storage
node.
This waits for a period of time and ensures that data synchronization has
completed after the upgrade of a controller or storage 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