Provide RFC for Salt SSH for TU systems

[m-czernek]

Related research: https://github.com/SUSE/spacewalk/issues/24809

[rjmateus]

Just one note from my side, other then that looks good to me. Lets also wait for ION squad team members review

[rjmateus]

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?

[m-czernek]

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.

[aaannz]

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

[m-czernek]

I'm not sure I understand here. This RFC is about requiring the users to use the state or transactional_update modules based on their needs:

Users should use the state module modify OOT filesystem, and the transactional_update module to modify the IAT filesystem.

So if I'm not misunderstanding, we already suggest that user use the transactional_update when necessary. This leads us to changing how Uyuni/SUMA deals with TU minions as well.

Regarding:

i.e. instead of pkg.installed suggest using transaction_pkg.installed?

It would work for some changes, e.g. changes that do not require other files, like the pkg.installed you mention. It would not work for changes that require anything on the filesystem, e.g.:

• modules that execute sls files
• the file command that copies a file to a different location, etc.

This would require the same synchronization mechanism as we provide in this RFC.

I can add it to alternative solutions with the caveat that we'd support only a subset of Uyuni's functionality (and of course, we'd also have to re-do how we treat TU minions on Uyuni's side since neither state.apply nor transactional_update.apply would work)