[FEATURE REQUEST] salt-ssh configurable thin client compression

[nergdron]

Is your feature request related to a problem? Please describe. I use salt-ssh to manage servers around the world, and one of the biggest issues I run into is that deploying the thin client across a large number of hosts can take a really long time, even if the actual operations performed once its there don't.

Describe the solution you'd like I'd like to be able to specify the cli compressor and decompressor for the thin client tarball, so that I have a lot less data to send. given the option, I'd likely use zstd or xz, which could reduce my current thin tarball from ~11MB to ~6MB, a huge speed improvement.

Describe alternatives you've considered

• if the thin client could be provided to the hosts in question via https, they have a caching web proxy configured, and this could provide even greater speed boosts. however this would require starting a web server as part of the salt-ssh run.
• if the thin client tarball could be provided via ipfs, that would also auto-scale the distribution in an even nicer way. however this would require ensuring the target host has an ipfs client properly configured, which is certainly not a guarantee, or require trusting public ipfs gateways.

either one of these would scale better for me, but would require complex setup that I doubt salt-ssh wants to undertake. plus, they'd leave the thin tarball in caches other places, which is likely a security problem. if salt-ssh encrypted the tarball at its end and then decrypted it at the other end, that wouldn't be so bad. but I still think it's too complex with too many moving parts.

[waynew]

Not necessarily a question about the feature, but have you considered just using regular salt? Also heist (https://pypi.org/project/heist-salt/) might be interesting. Not sure if it supports this out of the box :thinking:

[nergdron]

@waynew we have, but like most folks these days, we have hosts distributed across a number of cloud providers, physical boxes, and other computing environments. in many of them, we'd like to use salt, but deploying a salt server is non-trivial, especially from a cost perspective. for a salt server to be deployed in every environment, we'd end up increasing our instance count by as much as 1/3rd, which is basically a non-starter from a costing perspective.

there's ways we could try and work around this, but salt-ssh is a pretty natural fit for us. especially since we're looking at using salt to replace an existing ansible codebase, and integrate with terraform, neither of which require agents or centralized servers. honestly, that old centralized automation server design is really showing its age at this point, given the diversity of computing environments most folks want to deploy to these days.

[waynew]

From my perspective, I think that this is a good feature, but it has some risks (e.g. we support native minions on arista, juniper, etc. - how would this apply?) so I think that I'll ask - can you create a Salt Enhancement Proposal? That way we can get it in front of the broader community and hash out some of those challenges.

https://github.com/saltstack/salt/blob/5e6f2d69600b3ae20493f4dd28c940f1e733d087/salt/utils/thin.py#L676 is a place that would be good to reference in the SEP.

[nergdron]

@waynew finally got a chance to do this, SEP is here: https://github.com/saltstack/salt-enhancement-proposals/pull/58