Use "salt-ssh" to provisioning instead of installing Salt inside the sumaform machines

[meaksh]

This is an enhancement.

Currently sumaform needs salt to be installed on vm (also the entire sumaform file_root) in order to provision them and apply the sumaform states.

We can use salt-ssh instead to make provisoning cleaner and prevent salt from being installed on the deployed machines.

[MalloZup]

@meaksh @moio, i'm not sure if this is really an enhancement.

If is an enhancement, then on "cleaness" of vms, but we loose definetely on performance, afaik

Consider following scenario (like we have in production)

sumaform control-node --> KVM-SERVER -> vms(salt-inside)

This will imply that we loose extra-time, when applying the salt-ssh state.

Could we maybe mesure how much time for creating vms we will need before switching to salt-ssh?

[mbologna]

Just bouncing here to say: if we don't install salt* packages on the minion, less disk space is required

[moio]

Just bouncing here to say: with salt-ssh "The Tarball" is copied over to the minion at apply time, and that will consume bandwidth some (maybe not much) disk space.

A hackotype (hack/prototype) would be interesting!

[MalloZup]

I'm basically a fun for salt-ssh, regarding also the efford made by duncan: https://github.com/saltstack/salt/pull/39754

is a good move imho, but as moio say, we should need an hackotype, to see how much we loose in term of performance. (If we loose like 30 min) i'm still ok, i just don't want that we need like 20h for doing it 2H

[MalloZup]

@meaksh it might be cool from you to have a benchmark for this if you want this feature.

adding this label later