Merge "Patching on Debian: Additional configs + orchestration support"

doc/source/updates/kubernetes/configuring-update-orchestration.rst

@@ -44,7 +44,7 @@ You cannot successfully create an update \(patch\) strategy if any hosts show
 **Patch Current** = **Pending**, indicating that the update status of these
 hosts has not yet been updated. The creation attempt fails, and you must try
 again. You can use :command:`sw-patch query-hosts` to review the current update
-status before creating a update strategy.
+status before creating an update strategy.
 
 .. rubric:: |proc|
 
@@ -63,10 +63,10 @@ status before creating a update strategy.
        :height: 365px
        :width: 475px
 
-#.  Create a update strategy by specifying settings for the parameters in the
+#.  Create an update strategy by specifying settings for the parameters in the
     Create Strategy dialog box.
 
-    **Description** field
+    **Description**
         Provides information about current alarms, including whether an alarm
         is Management Affecting.
 
@@ -172,7 +172,7 @@ status before creating a update strategy.
 
 #.  To abort the update, click the **Abort Strategy** button.
 
-    -   While a update-strategy is being applied, it can be aborted. This
+    -   While an update-strategy is being applied, it can be aborted. This
         results in:
 
         -   The current step being allowed to complete.
@@ -181,14 +181,14 @@ status before creating a update strategy.
             attempt to unlock any hosts that were locked.
 
     .. note::
-        If a update strategy is aborted after hosts were locked, but before
+        If an update strategy is aborted after hosts were locked, but before
         they were updated, the hosts will not be unlocked, as this would result
         in the updates being installed. You must either install the updates on
         the hosts or remove the updates before unlocking the hosts.
 
 #.  Delete the update strategy.
 
-    After a update strategy has been applied \(or aborted\) it must be deleted
-    before another update strategy can be created. If a update strategy
+    After an update strategy has been applied \(or aborted\) it must be deleted
+    before another update strategy can be created. If an update strategy
     application fails, you must address the issue that caused the failure, then
     delete and re-create the strategy before attempting to apply it again.

doc/source/updates/kubernetes/managing-software-updates.rst

@@ -61,6 +61,10 @@ The following elements form part of the software update environment:
         This records user actions that involve software updates, performed
         using either the CLI or the REST API.
 
+    **patching-insvc.log**
+        This records the execution of patch scripts while in-service patches are
+        applied.
+
 The overall flow for installing a software update from the command line
 interface on a working |prod| cluster is the following:
 

doc/source/updates/kubernetes/software-update-space-reclamation.rst

@@ -11,9 +11,8 @@ versions of software updates once newer versions have been committed.
 
 The :command:`sw-patch commit` command allows you to “commit” a set of software
 updates, which effectively locks down those updates and makes them unremovable.
-In doing so, |prod-long| is then able to delete package files with lower
-versions from the storage and repo, keeping only the highest version of each
-package in the committed software update set.
+In doing so, |prod-long| is able to free up the disk space in patch storage and
+the software repo.
 
 .. caution::
     This action is irreversible.

doc/source/updates/kubernetes/software-updates-and-upgrades-software-updates.rst

@@ -50,10 +50,10 @@ the |prod| software:
 
 .. _software-updates-and-upgrades-software-updates-ol-kxm-wgv-njb:
 
-#.  **RPM Software Updates**
+#.  **Software Updates**
 
-    These software updates deliver |prod| software updates containing RPMs for
-    updating the |prod| software running directly on the hosts.
+    These software updates deliver |prod| software updates containing ostree
+    commits for updating the |prod| software running directly on the hosts.
 
     Software updates can be installed manually or by the Update Orchestrator
     which automates a rolling install of an update across all of the