Salt Shaker: allow testing "python311-salt" in SLMicro and Tumbleweed

[meaksh]

What does this PR change?

This PR just enhances the mechanism to install the classic Salt package on Salt Shaker environments, so Python 3.11 is used for SLMicro and Tumbleweed

[agraul]

I would prefer an approach that does not require manual changes when Tumbleweed or MicroOS changes the primary Python version (assuming we'll start testing MicroOS as well at some point).

Zypper can use --capability to work on rpm provides, for package installations that's the default fallback and does not require these changes. transactional-update pkg install might take the same flag, that's something we can check.

[meaksh]

@agraul I just took this other approach to not hardcode the primary interpreter version (which we are already using at https://github.com/uyuni-project/sumaform/blob/master/salt/salt_testenv/postinstallation.sls). For now, I just want to fix the current failures we have in our Jenkins jobs for SLMicro 6.0. What do you think?

[agraul]

I still don't get the need to specify any version. Can you point me to a deployment failure log where I can see what's being installed and why that's not the right package?

[meaksh]

The current problem on SLMicro60, is that python311-salt is now part of the VM image (it is preinstalled). The current preinstalled package is our initial iteration on the singlespec approach, that got released already, which contains an Obsoletes: python3-salt < %{version}.

So, given this python311-salt is preinstalled, then the sumaform deployment fails here when trying to install python3-salt here. We see:

(remote-exec): Problem: 1: the installed python311-salt-3006.0-9.1.x86_64 obsoletes 'python3-salt < 3006.0-9.1' provided by the to be installed python3-salt-3006.0-8.1.x86_64
(remote-exec):  Solution 1: Following actions will be done:
(remote-exec):   deinstallation of python311-salt-3006.0-9.1.x86_64
(remote-exec):   downgrade of salt-3006.0-9.1.x86_64 to salt-3006.0-8.1.x86_64
(remote-exec):   downgrade of salt-minion-3006.0-9.1.x86_64 to salt-minion-3006.0-8.1.x86_64
(remote-exec):   downgrade of salt-transactional-update-3006.0-9.1.x86_64 to salt-transactional-update-3006.0-8.1.x86_64
(remote-exec):  Solution 2: do not install python3-salt-3006.0-8.1.x86_64
(remote-exec): Choose from above solutions by number or cancel [1/2/c/d/?]      

Jenkins job: https://ci.suse.de/user/manager/my-views/view/Salt%20Shaker/job/manager-salt-shaker-products-testing-slmicro60/

[agraul]

If I understand that output correctly, our problem is that we have an older release in our devel repository. That raises the question: don't we want to enforce that our package is installed? With your proposed changes, which Salt package will be installed at the end? The pre-installed package or the package from our salt_testing_repo?

[meaksh]

If I understand that output correctly, our problem is that we have an older release in our devel repository.

Not exactly... indeed we have a higher version-release in our salt_testing_repo, but the thing is that, before our singlespec changes, the salt_testing_repo was only building python3-salt package for SLMicro 6.0, while now our singlespec package builds python311-salt only for SLMicro 6.0.

The SLMicro 6.0 sumaform image contains salt-minion and python311-salt preinstalled, so when we ask to install python3-salt, it just found the old python3-salt packages from the alp source repo (and no "python3-salt" from our salt_testing_repo as it does not exist).

That raises the question: don't we want to enforce that our package is installed? With your proposed changes, which Salt package will be installed at the end? The pre-installed package or the package from our salt_testing_repo?

Yes, sure, with my proposal I just want to get the python311-salt installed coming from the salt_testing_repo (instead of "python3-salt"), for SLMicro 6.0 and TW.

[agraul]

If I understand that output correctly, our problem is that we have an older release in our devel repository.

Not exactly... indeed we have a higher version-release in our salt_testing_repo, but the thing is that, before our singlespec changes, the salt_testing_repo was only building python3-salt package for SLMicro 6.0, while now our singlespec package builds python311-salt only for SLMicro 6.0.

Are you sure the version in salt_testing_repo is higher? What you posted says that the to-be-installed package has a lower version-release.

Problem: 1: the installed python311-salt-3006.0-9.1.x86_64 obsoletes 'python3-salt < 3006.0-9.1' provided by the to be installed python3-salt-3006.0-8.1.x86_64

Yes, sure, with my proposal I just want to get the python311-salt installed coming from the salt_testing_repo (instead of "python3-salt"), for SLMicro 6.0 and TW.

And this does not work with --capability? That's too bad, this workaround is brittle and will require future changes.

[meaksh]

If I understand that output correctly, our problem is that we have an older release in our devel repository.

Not exactly... indeed we have a higher version-release in our salt_testing_repo, but the thing is that, before our singlespec changes, the salt_testing_repo was only building python3-salt package for SLMicro 6.0, while now our singlespec package builds python311-salt only for SLMicro 6.0.

Are you sure the version in salt_testing_repo is higher? What you posted says that the to-be-installed package has a lower version-release.

Yes, even it this sounds strange, it is actually the higher version:

salt-shaker-products-testing-slmicro60:~ # zypper search -s python311-salt
Loading repository data...
Reading installed packages...

S  | Name                     | Type    | Version     | Arch   | Repository
---+--------------------------+---------+-------------+--------+---------------------------------
v  | python311-salt           | package | 3006.0-78.1 | x86_64 | salt_testing_repo
i  | python311-salt           | package | 3006.0-9.1  | x86_64 | alp_sources_repo
i  | python311-salt           | package | 3006.0-9.1  | x86_64 | os_pool_repo
   | python311-salt-test      | package | 1.4-1.2     | noarch | salt_testsuite_dependencies_repo
   | python311-salt-testsuite | package | 3006.0-78.1 | x86_64 | salt_testing_repo
   | python311-salt-testsuite | package | 3006.0-9.1  | x86_64 | alp_sources_repo

    Note: For an extended search including not yet activated remote resources please use 'zypper
    search-packages'.

Problem: 1: the installed python311-salt-3006.0-9.1.x86_64 obsoletes 'python3-salt < 3006.0-9.1' provided by the to be installed python3-salt-3006.0-8.1.x86_64

Yes, sure, with my proposal I just want to get the python311-salt installed coming from the salt_testing_repo (instead of "python3-salt"), for SLMicro 6.0 and TW.

And this does not work with --capability? That's too bad, this workaround is brittle and will require future changes.

It doesn't work with --capability python3-salt, I must set the exact version to get the resolution to work as we expect. I can prepare a patch that would work that way.

It does not work with:

# transactional-update -c -n pkg in --capability python3-salt-testsuite python3-salt-test python3-salt
-failed, it says nothing to update-

# transactional-update -c -n pkg in --capability python3-salt-testsuite-3006.0-78.1 python3-salt-test python3-salt-3006.0-78.1
-successfull installation of python311-3006.0-78.1 using capabilities-

I'll push an extra commit with an alternative approach based on --capability usage. Thanks 👍

[meaksh]

@agraul with this latest change, we use --capability and it works, but it is really hacky the way to get the appropiated salt version, as jinja2 variables are rendered before we setup all the respositories, so we cannot really use it.