docs: small fixes for transactional update

This will fix some spellings and layout issues.

Signed-off-by: Dominik Gedon <[email protected]>
(cherry picked from commit 5300cc4)

salt/modules/transactional_update.py

@@ -6,7 +6,7 @@
 A transactional system, like `MicroOS`_, can present some challenges
 when the user decided to manage it via Salt.
 
-MicroOS provide a read-only rootfs and a tool,
+MicroOS provides a read-only rootfs and a tool,
 ``transactional-update``, that takes care of the management of the
 system (updating, upgrading, installation or reboot, among others) in
 an atomic way.
@@ -128,7 +128,7 @@
 
 For example::
 
-  transactional-update --continue --drop-if-no-change run zypper in apache2"
+  transactional-update --continue --drop-if-no-change run zypper in apache2
 
 If we are in the scenario described before, ``apache2`` is already
 present in T.3.  In this case a new transaction, T.4, will be created
@@ -240,11 +240,11 @@
 Two step for service restart
 ............................
 
-In the ``apache2` example from the beginning we can observe the
+In the ``apache2`` example from the beginning we can observe the
 biggest drawback.  If the package ``apache2`` is missing, the new
 module will create a new transaction, will execute ``pkg.install``
 inside the transaction (creating the salt-thin, moving it inside and
-delegating the execution to `transactional-update` CLI as part of the
+delegating the execution to ``transactional-update`` CLI as part of the
 full state).  Inside the transaction we can do too the required
 changes in ``/etc`` for adding the new ``vhost``, and we can enable the
 service via systemctl inside the same transaction.
@@ -557,8 +557,8 @@ def kdump(self_update=False, snapshot=None):
 def run(command, self_update=False, snapshot=None):
     """Run a command in a new snapshot
 
-    Execute the command inside a new snapshot. By default this snaphot
-    will remain, but if --drop-if-no-chage is set, the new snapshot
+    Execute the command inside a new snapshot. By default this snapshot
+    will remain, but if --drop-if-no-change is set, the new snapshot
     will be dropped if there is no change in the file system.
 
     command
@@ -920,7 +920,7 @@ def call(function, *args, **kwargs):
 
     activate_transaction
         If at the end of the transaction there is a pending activation
-        (i.e there is a new snaphot in the system), a new reboot will
+        (i.e there is a new snapshot in the system), a new reboot will
         be scheduled (default False)
 
     CLI Example:
@@ -991,7 +991,7 @@ def apply_(mods=None, **kwargs):
 
     activate_transaction
         If at the end of the transaction there is a pending activation
-        (i.e there is a new snaphot in the system), a new reboot will
+        (i.e there is a new snapshot in the system), a new reboot will
         be scheduled (default False)
 
     CLI Example:
@@ -1030,15 +1030,15 @@ def sls(mods, activate_transaction=False, queue=False, **kwargs):
 
     activate_transaction
         If at the end of the transaction there is a pending activation
-        (i.e there is a new snaphot in the system), a new reboot will
-        be scheduled (default False)
+        (i.e there is a new snapshot in the system), a new reboot will
+        be scheduled (Default: False).
 
     queue
         Instead of failing immediately when another state run is in progress,
         queue the new state run to begin running once the other has finished.
 
         This option starts a new thread for each queued state run, so use this
-        option sparingly. (Default: False)
+        option sparingly (Default: False).
 
     For a formal description of the possible parameters accepted in
     this function, check `state.sls` documentation.
@@ -1075,15 +1075,15 @@ def highstate(activate_transaction=False, queue=False, **kwargs):
 
     activate_transaction
         If at the end of the transaction there is a pending activation
-        (i.e there is a new snaphot in the system), a new reboot will
-        be scheduled (default False)
+        (i.e there is a new snapshot in the system), a new reboot will
+        be scheduled (Default: False).
 
     queue
         Instead of failing immediately when another state run is in progress,
         queue the new state run to begin running once the other has finished.
 
         This option starts a new thread for each queued state run, so use this
-        option sparingly. (Default: False)
+        option sparingly (Default: False).
 
     CLI Example:
 
@@ -1117,15 +1117,15 @@ def single(fun, name, activate_transaction=False, queue=False, **kwargs):
 
     activate_transaction
         If at the end of the transaction there is a pending activation
-        (i.e there is a new snaphot in the system), a new reboot will
-        be scheduled (default False)
+        (i.e there is a new snapshot in the system), a new reboot will
+        be scheduled (Default: False).
 
     queue
         Instead of failing immediately when another state run is in progress,
         queue the new state run to begin running once the other has finished.
 
         This option starts a new thread for each queued state run, so use this
-        option sparingly. (Default: False)
+        option sparingly (Default: False).
 
     CLI Example: