How to package and upgrade to Salt 3008.x #94
Conversation
meaksh
force-pushed
the
master-salt-3008
branch
from
9d52b71
to
f7b0c64
Compare
| 1. Creating separated packages for each one of the Salt Extensions (potentially hundreds) -> maybe too cumbersome if we go with all of them, and probably not really needed. | ||
| 2. Do not package Salt Extensions at all -> builtin extensions + manual customization. | ||
|
|
||
| With option 1, we do package and do support all those extensions we decide to have a package for. On the other hand, with option 2, we do only take care of maintaing and supporting the reduced list of builin extensions (actually integrated in the main `python311-salt` package), and then users and customers would need to rely on extending with their desired extensions coming from the community. |
There was a problem hiding this comment.
There could be a third option, packaging a curated list of salt extensions. The benefit would be that Uyuni can mirror RPM repos, but not PyPI. Our current extension approach requires internet access or an independent PyPI mirror.
I don't think it's worthwhile to package all extensions, this is a good opportunity to focus our efforts on the Salt extensions that are popular and make sure we can test them as well.
| - docker / dockerng | ||
| - ... | ||
|
|
||
| These are the minimum required extensions to be able to do basic operations in SUSE/openSUSE distributions and also allow basic operations on the context of SUSE Manager clients. |
There was a problem hiding this comment.
How do we package them? To we put build them separately as salt extensions (each with their own git repo to track the sources & specfile, following the new "The one and only one git workflow") and then use those as build requirements when building salt? Or do you want to pull them all into the same package git repo?
|
|
||
| ### New dependencies for Salt 3008. | ||
|
|
||
| There are new dependencies that are not available as part of "SLE-Module-Python3", and we will need to take it from Factory or some other SLE/ALP source to include them in the new "SLE-Module-Salt" module. |
There was a problem hiding this comment.
Since these are libraries, they might also fit the Python3-Module. We should check with the SLE PMs
| - `python-pandas` -> python-versioneer-toml | ||
| - `python-scipy` -> python-pythran | ||
|
|
||
| A testing build project is here: https://build.suse.de/project/show/home:PSuarezHernandez:new-salt-version |
There was a problem hiding this comment.
Could we have this in OBS, so that everyone with access to this repo can take a look?
|
@meaksh do you think it would make sense to also mention the upgrade strategy across SUMA versions? Should we upgrade suma 4.3 to salt 3008, no matter when it's released? How this relates to suma 4.3 LTS. Also I don't see any reference to salt-minion, so I'm assuming it's being updated at same time as the server (which can influence how and when we upgrade suma 4.3 to 3008). |
|
|
||
| This list could be reduced even more by just providing the `zypperpkg` and `transactional_update` modules and then providing the rest via `/usr/share/susemanager/salt/[_modules,_states,...]` in the Uyuni / SUSE Manager server. | ||
|
|
||
| Builtin Salt Extensions will be integrated into our main "openSUSE/salt" GitHub repo codebase for 3008.x, and provided as content of the main `python311-salt` package. |
There was a problem hiding this comment.
How do we do that? Do we use git submodules? What happens to e.g. zypperpkg upstream? Shouldn't we take ownership and maintain it as an extension?
There was a problem hiding this comment.
I've added some notes on this regard.
There was a problem hiding this comment.
The "what" is pretty good, but I think we could think a bit more about the "how". SUSE proposed a "one and only" git-based packaging workflow for new products. While we don't have to go all the way there, it would be a good time to explore a better integrated git-packaging workflow that the one we currently have.
|
|
||
| These builtin extensions will be then placed in `/usr/lib/python3.11/site-packages/saltext/` when installing `python311-salt` so they are available for Salt. | ||
|
|
||
| **NOTE:** The usage of `git submodule` would make it a bit tricky when it comes to generate patches for the single unified Salt codebase, as apparentely you cannot get an unified diff for the main repo + submodules. |
There was a problem hiding this comment.
Why do need to generate patches?
There was a problem hiding this comment.
I slightly modified the text, as generating patches would depend on the maintaining workflow we use.
| ... | ||
| ``` | ||
|
|
||
| The idea would be to include the releases for the different builtin extension directly inside our GH repo, as it was previously done with "tornado". We should take this oportunity also to take the ownership, migrate and create the official `saltext-zypperpkg` extension and probably some others. |
There was a problem hiding this comment.
How do we do scm on these directories? How do make sure we contribute our changes upstream and then pull them down? How do we publish extensions maintained by us to PyPI?
There was a problem hiding this comment.
Yeah, all these questions must be still clarified and defined in a new maintaining worflow for Salt.
I added a note on the current RFC mentioning that we are covering the "new maintining workflow for Salt" in a separated RFC, so we can agree on the proposed plan here for the Salt 3008 upgrade, and start pushing it forward while we keep discussing and designing the new maintaining workflow.
meaksh
changed the title
meaksh
requested review from
ycedres,
mcalmer,
deneb-alpha,
rjmateus,
admd,
m-czernek,
vzhestkov and
agraul
| #### SLE15: | ||
| - A new custom "SLE-Module-Salt" module (inherited from SLE-Module-Python3) will be created for SLE15SP4/5/6/7. | ||
| - The new Salt 3008.x package will be shipped via the new "SLE-Module-Salt" together with its any new dependency which is not part of the "SLE-Module-Python3" module. | ||
| - The old Salt 3006.0 package in SLE15SP4/5/6 will be deprecated in favor of the new version coming in the new "SLE-Module-Salt". | ||
| - The old Salt 3006.0 package will be dropped from SLE15SP7 Basesystem and Server Application modules before SLE15SP7 feature cutoff. | ||
|
|
||
| #### Leap15: | ||
| - Python 3.11 is already available in Leap. | ||
| - The new Salt and any new dependencies will get into Leap from SLE. | ||
|
|
||
| NOTE: SLMicro 6.0 works differently than SLE15, as it does contain Python 3.11 in the base channels. |
There was a problem hiding this comment.
You should say also something about SLES12 SP5 LTSS and maybe about other OSes when it comes to SUMA.
AFAIK venv-salt-minion is the only affected package on these platforms as we do not have master and proxy there?
There was a problem hiding this comment.
The classic Salt package is already EOL in SLE12, as it was part of the "Advanced Systems Management Module" which does not have LTSS. The version there was actually Salt 3000, as 3006.0 was not even supported.
For RES8 and Ubuntu 20.04 (client tools), we still ship a classic Salt package (3006.0), I'll add some notes to the RFC also on this regard.
There was a problem hiding this comment.
I just added some notes to cover the cases for other OSes.
| - Uyuni will get automatically 3008 from SLE into Leap (June 2025). | ||
| - Current upstream Salt 3006 EOL date is January 2026, but potentially extended if 3008 is delayed, so worst scenario we are 6 months in our own (probably less). | ||
|
|
||
| b2) If Salt 3008 is NOT ready when SUMA 4.3 LTS begins (June 2025) -> We keep Salt 3006.0 for all SPs until LTS ends (June 2026): |
There was a problem hiding this comment.
if salt 3008 doesn't get released in time I think this would be the best approach, since it avoids the need to support 2 salt major versions at the same time.
Read the RFC here