Provide RFC for Salt SSH for TU systems #93
Conversation
| - `state` (e.g. `state.apply`) | ||
| - `transactional_update` (e.g. `transactional_update.apply`) | ||
|
|
||
| Users should use the `state` module modify OOT filesystem, and the `transactional_update` module to modify the IAT filesystem. |
There was a problem hiding this comment.
This means that they cannot be mixed together in the same state? So any OOT state should be defined in it's own sls file and executed with state.apply, and any states that needs to modify IAT should be in a different sls file and executed with transational_update.apply.
Do we have any state that modifies files/data in both locations?
There was a problem hiding this comment.
Correct. Users must specify whether they want to run a state inside, or outside of a transaction, and execute either state.apply, or transactional_update.apply.
Do we have any state that modifies files/data in both locations?
This is not possible, at least not without some significant modifications to Salt at a quite low level. Salt does not give us control at a more fine-grained level than the whole execution.
m-czernek
changed the title
| Currently, when Uyuni bootstraps a minion by using Salt SSH, Uyuni deploys a Salt client into `/var/tmp/venv-salt-minion`. | ||
| When Salt SSH makes a `state` call to a client, for example `state.sls example-sls-filename`, it additionally compiles the `example-sls-filename` state (and all its dependencies, such as files used by the state) into a tar file, and deploys it to a generated location in `/var/tmp`, such as `/var/tmp/.root_12345_salt/salt_state.tgz` (together with other data, such as external modules, grain info, etc). | ||
|
|
||
| TU minions are different from non-TU minions in that they mount some partitions as read-only, for example `/etc`. To modify such partitions, users use the `transactional-update` command. |
There was a problem hiding this comment.
/etc is not read only. etc is an overlay and is read-write.
| TU minions are different from non-TU minions in that they mount some partitions as read-only, for example `/etc`. To modify such partitions, users use the `transactional-update` command. | |
| TU minions are different from non-TU minions in that they mount some partitions as read-only, for example `/usr`. To modify such partitions, users use the `transactional-update` command. |
|
|
||
| TU minions are different from non-TU minions in that they mount some partitions as read-only, for example `/etc`. To modify such partitions, users use the `transactional-update` command. | ||
|
|
||
| The `transactional-update` command temporarily mounts the partitions as read-write, and after the modifications are done, it creates a new BTRFS snapshot that is activated upon restart (or upon using `transactional-update apply`). |
There was a problem hiding this comment.
This is technically not correct.
TU first creates a new read-write snapshot of currently running snapshot (or latest if -c is used) and at the end set this new snapshot as default one for next reboot.
It does not remount anything as rw even temporarily.
| # Alternatives | ||
| [alternatives]: #alternatives | ||
|
|
||
| - Not supporting Salt SSH on TU systems. |
There was a problem hiding this comment.
Instead of "not supporting" salt ssh on TU systems, could we instead suggest using transactional_update execution module? Or can we even provide a transactional_update state which would wrap TU execution module?
i.e. instead of pkg.installed suggest using transaction_pkg.installed?
Of course this would open another can of worms like:
- users required to keep in mind mandatory reboot
- detect we are already running in the transaction via tu executor in normal salt
Related research: https://github.com/SUSE/spacewalk/issues/24809