SEP 8 - Python 3 Only Salt-SSH #11
Conversation
|
This SEP will be number 8, feel free to update your filename and SEP 🙂 |
Co-Authored-By: Ch3LL <[email protected]>
| will run as it always has. | ||
| 2. Add a Salt-SSH configuration (for example: pre_flight) to run raw commands before the | ||
| Salt-SSH command. This will allow a user to create a custom script they can run to install | ||
| Python 3. It will only run these pre_flight commands if the tarball is not copied over. |
|
|
||
| How are we going to build the Python 3 binary? | ||
| We will build the binary statically for both x86_64 and ARM architecture. We will include the x86_64 | ||
| binary by default in the Salt-SSH package. If the ARM architecture is detected we will include a warning |
There was a problem hiding this comment.
As long as there is a way to upgrade this, like you can with salt-cloud -u for the bootstrap script, i think this is fine.
There was a problem hiding this comment.
Great suggestion :) Added here:
| ## Unresolved questions | ||
| [unresolved]: #unresolved-questions | ||
|
|
||
| When we build the static python build we will need to review the licenses of all the libraries included in the build. |
There was a problem hiding this comment.
It would be good to have possibly a dashboard or an easy way for salt to be alerted about any CVEs in dependencies.
This might be really easy to do using github and their security alerts
https://help.github.com/en/articles/about-security-alerts-for-vulnerable-dependencies
or using pyup.
There was a problem hiding this comment.
I added this to the Python Binary Security Releases: paragraph instead as i thought that made sense.
There was a problem hiding this comment.
Awesome, LGTM!
It would be nice if the preflight_cmd could point to a script that would be transferred over. But i don't think it is necessarily required since the "script" could be added in a multiline string in yaml. or if the preflight_cmds was a list of commands to run.
|
Just as a note here. We're currently solving this situation in a different way based on the changes that were introduced here: saltstack/salt#46684 At SUSE, we're still dealing even with old Python 2.6 systems and we use In order to do that, we provide a What I like from the approach that RFC provides is that this will keep all functionality & features that the latest Salt (based on Python3 and installing on the master) when targeting a system with an older Python version, instead of having to different codebase and do backporting or arrange SLS to keep the compatibility. On the other hand, I'm a bit worried about the problems with other Python dependencies (apart from SaltSSH) that might be required from the Python3-based execution & state modules that are been executed as part of the particular action that the IIUC, those libraries required by any execution & state modules that is going to be executed would need to be added as [1] - https://build.opensuse.org/package/show/systemsmanagement:saltstack:products/py26-compat-salt |
If the user is using If they are using a different approach such as the python3 system library, they can use a |
| ## Alternatives | ||
| [alternatives]: #alternatives | ||
|
|
||
| Alternatives for Python 3 static binary: |
There was a problem hiding this comment.
Have we ever considered something like PyInstaller to package a binary with python and all its dependencies?
Ch3LL
added
Accepted
and removed
Final Comment Period
No description provided.