saltstack/salt
1
0
Fork 0
mirror of https://github.com/saltstack/salt.git synced 2025-04-16 17:50:20 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

docs: small fixes for transactional update

Browse source 
This will fix some spellings and layout issues.

Signed-off-by: Dominik Gedon <dominik.gedon@suse.com>
This commit is contained in:
Dominik Gedon 2023-04-20 13:59:35 +02:00 • committed by Gareth J. Greenaway
parent 894c26780d
commit 5300cc451c
1 changed files with 17 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

34
salt/modules/transactional_update.py
View file

@ -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 @@ transaction will remain, if not it will be discarded.
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 @@ restarting a service inside transaction is not allowed).
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: