[FEATURE REQUEST] Add --relenv Option to salt-ssh for Using a Onedir Bundled Version of Salt+Python

[Akm0d]

Summary:

This feature request proposes adding a --relenv option to salt-ssh that allows downloading and using a bundled version of Salt and Python (relenv) on the SSH target, similar to how the --thin option works. This will serve as a transitional feature towards making relenv the default method for Salt-SSH deployments in the future.

Description:

Currently, salt-ssh uses the --thin option to copy a minimal version of Salt to the SSH target, along with Python dependencies, and then run Salt remotely. However, with the increasing preference for using relenv bundled environments (Salt and Python packaged together), it would be ideal to introduce a --relenv option that downloads and uses a one-directory (onedir) version of Salt+Python on the target machine.

The --relenv option would follow a similar flow as --thin, but instead of copying a minimal installation, it would download and unpack a relenv bundle (which includes both Salt and Python). This could be useful for environments where managing Python versions and dependencies on the target machine is difficult or where a fully isolated environment is desired.

Expected Behavior:

When a user runs salt-ssh with the --relenv option, Salt should:

1. Check for relenv support on the target: Ensure that the target system can support the relenv bundle.
2. Download the relenv bundle: Retrieve the pre-packaged Salt+Python bundle (possibly from a pre-configured URL or file server).
3. Extract and use: Extract the bundle on the target and use it to run Salt commands.
4. Handle clean-up: Optionally clean up the environment after execution (if the user specifies this).

This option will allow users to run Salt on machines that may not have Salt or Python pre-installed or where version conflicts exist.

Proposed CLI Syntax:

salt-ssh --relenv <target> test.ping

Additional options for managing the relenv bundle can include paths to the local or remote onedir package, force re-download, etc.

Justification:

The relenv bundle represents the future direction for Salt deployments, and adding this as an optional feature in salt-ssh will enable users to transition smoothly to the new system. It also simplifies Salt-SSH deployments on targets that have conflicting or missing Python versions and dependencies.

Current Behavior:

The current salt-ssh approach uses --thin to transfer a lightweight Salt environment. This requires Python to be present on the target and can run into compatibility issues depending on the target’s system configuration.

Additional Context:

• Once stabilized, relenv can eventually become the default for salt-ssh.
• This facilitates using salt-ssh to bootstrap salt on the targets
• This will facilitate the deployment of ephemeral minions with salt-ssh

[Akm0d]

Implementation Discussion:

Question: Should we re-use the --thin options for the deploy directory when using --relenv, or should we create completely separate options for relenv deployment?

• The options will be mutually exclusive, meaning you'll either use --thin or --relenv, not both simultaneously. Therefore, it should be fine to re-use the thin_dir options for relenv deployment as well.

Consensus:

• Agreed to re-use the thin_dir options for --relenv deployments.
• General preference to re-use existing logic where possible.

Additional Consideration:

• Question: Should --relenv check for and replace existing --thin deployments, or should it follow the current behavior of doing nothing if the thin_dir is already populated?

  • Response: For now, we'll keep the existing logic and maintain the behavior of doing nothing if the deployment directory (thin_dir) is already occupied.