Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings
This repository was archived by the owner on Jan 24, 2024. It is now read-only.

SEP 8 - Python 3 Only Salt-SSH#11

Merged
garethgreenaway merged 6 commits intosaltstack:masterfromCh3LL:add_ssh_py3
Jul 10, 2019

Conversation

@Ch3LL
Copy link
Contributor

No description provided.

@waynew
Copy link
Contributor

This SEP will be number 8, feel free to update your filename and SEP 🙂

@Ch3LLCh3LL changed the titlePython 3 Only Salt-SSHSEP 8 - Python 3 Only Salt-SSHMay 1, 2019
waynewand others added2 commitsMay 1, 2019 11:47
Co-Authored-By: Ch3LL <megan.wilhite@gmail.com>
Copy link

@gtmanfredgtmanfred left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I have two things that I would like to see added to the proposal, otherwise i think this is great.

Thanks!
Daniel

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

👍


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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

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.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Great suggestion :) Added here:

7cda959

## 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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

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.

https://pyup.io/safety/

waynew reacted with thumbs up emoji
Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I added this to thePython Binary Security Releases: paragraph instead as i thought that made sense.

16dc67f

Copy link

@gtmanfredgtmanfred left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

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.

@Akm0dAkm0d self-requested a reviewMay 3, 2019 15:31
@meaksh
Copy link

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 usesalt-ssh from a Python3 master to deal with them.

In order to do that, we provide apy26-compat-salt package [1] (based on 2016.11.10) which is installed on the master as an alternative salt codebase (outside /usr/lib/) and we provide also the necessaryssh_ext_alternatives settings [2] in order to use that codebase when dealing with Python 2.6 in the target system.

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 thesalt-ssh call is performing and are not available on a Python2 targeted system.

IIUC, those libraries required by any execution & state modules that is going to be executed would need to be added asssh_ext_alternatives, right?

[1] -https://build.opensuse.org/package/show/systemsmanagement:saltstack:products/py26-compat-salt
[2] -https://build.opensuse.org/package/view_file/systemsmanagement:saltstack:products/py26-compat-salt/py26-compat-salt.conf?expand=1

@Ch3LL
Copy link
ContributorAuthor

IIUC, those libraries required by any execution & state modules that is going to be executed would need to be added as ssh_ext_alternatives, right?

If the user is usingssh_ext_alternatives then yes they would need to define the libraries there. My understanding is that this is how it currently works.

If they are using a different approach such as the python3 system library, they can use apip.install state/module to install the libraries similar to how users would currently do so.

@Ch3LLCh3LL added the Final Comment PeriodSpeak now or forever hold your peace. labelJul 1, 2019
## Alternatives
[alternatives]: #alternatives

Alternatives for Python 3 static binary:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Have we ever considered something likePyInstaller to package a binary with python and all its dependencies?

Sign up for freeto subscribe to this conversation on GitHub. Already have an account?Sign in.

Reviewers

7 more reviewers

@waynewwaynewwaynew left review comments

@s0undt3chs0undt3chs0undt3ch approved these changes

@thatch45thatch45thatch45 approved these changes

@garethgreenawaygarethgreenawaygarethgreenaway approved these changes

@gtmanfredgtmanfredgtmanfred approved these changes

@dwozdwozdwoz approved these changes

@Akm0dAkm0dAkm0d approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

9 participants

@Ch3LL@waynew@meaksh@s0undt3ch@thatch45@garethgreenaway@gtmanfred@dwoz@Akm0d

[8]ページ先頭

©2009-2025 Movatter.jp