Split client tools file #1859

maximenoel8 · 2025-06-24T03:11:33Z

What does this PR change?

The new MLM naming will be too complex to support in a single repos/client_tools.sls file.
To handle this, I propose splitting the file into three, as follows:

client_tools_suma.sls for 4.3 and 5.0 (and salt shaker ?)
client_tools_mlm.sls for 5.1 and head
client_tools_uyuni.sls for uyuni (and salt shaker ?)

I also refactored the deblike and rhellike blocks to simplify maintenance.

Approach

I tried to follow the existing structure but found some inconsistencies. These are summarized in the RelEng review section.

The overall repository setup for MLM and SUMA follows this pattern:
Each client will have those repositories.

Each client will have a base set of repositories:
- Product Repository and Update Repository by default
  - (both for SUMA, only update for deblike, only product for slmicro)
If the product version contains beta, beta repositories will be added
If the product version is nightly or head, the appropriate devel repositories will be added as well

Examples

5.1-nightly (SLES15 / SLEMicro):

tools_pool_repo => release pool repo
tools_update_repo => release update repo
tools_additional_repo => Devel:/Galaxy:/Manager:/5.1:/MLMTools

head (SLES15 / SLEMicro):

tools_pool_repo => release pool repo
tools_update_repo => release update repop 
tools_additional_repo => Devel:/Galaxy:/Manager:/Head:/MLMTools-Beta-

5.1-beta (SLES15 / SLEMicro):

tools_pool_repo => release pool repo
tools_update_repo => release update repo 
beta_tools_pool_repo => beta pool repo
beta_tools_update_repo => beta update repo

Uyuni:

uyuni-master will have both Stable and Master repos
uyuni-pr will have only Stable repos

Salt Shaker (no product version):
The current configuration is a mix of Uyuni and release URLs. It's unclear what is actually needed.

Related issue

https://github.com/SUSE/spacewalk/issues/27511

Verification needed by releng

Release repositories for 5.1

Should they be:

/SUSE/Updates/MultiLinuxManagerTools/MultiLinuxManagerTools => client , or
/SUSE/Updates/<Client>/MultiLinuxManagerTools ? (this one is empty for debian / ubuntu)
I’ve used the first option.

For RHEL on suma
Should we add the release update RHEL repositories by default for all clients?
This seems done for MLM and partially for Salt Shaker (e.g., using Uyuni stable for pool and EL9 update for update).
Example for alma9 on 5.0
New version will be:
tools_pool_repo : http://minima-mirror-ci-bv.mgr.suse.de/SUSE/Products/EL/9-CLIENT-TOOLS/x86_64/product/
tools_update_repo : http://minima-mirror-ci-bv.mgr.suse.de/SUSE/Updates/EL/9-CLIENT-TOOLS/x86_64/update/
tools_additional_repo : http://minima-mirror-ci-bv.mgr.suse.de/ibs/Devel:/Galaxy:/Manager:/5.0:/EL9-SUSE-Manager-Tools/SUSE_EL-9_Update_standard/
Verify repositories for slmicro6 for mlm
Please verify the nightly and head repository paths.
RES8 channel moved to EL8 for 5.1.
It appears to have moved to EL8 for 5.1.
RES7 Channel:
There's an inconsistency between RES7 and EL7 usage in release vs. devel:

http://dist.nue.suse.com/ibs/Devel:/Galaxy:/Manager:/5.1:/MLMTools-EL7/images/repo/ManagerTools-EL7-POOL-x86_64-Media/  
vs  
http://minima-mirror-ci-bv.mgr.suse.de/SUSE/Products/MultiLinuxManagerTools/RES-7/

How to use RCE repository in product ?

Current 5.0-nightly:

http://minima-mirror-ci-bv.mgr.suse.de/repo/$RCE/RES7-SUSE-Manager-Tools/x86_64/
http://minima-mirror-ci-bv.mgr.suse.de/ibs/Devel:/Galaxy:/Manager:/5.0:/RES7-SUSE-Manager-Tools/SUSE_RES-7_Update_standard/

Current 5.1-nightly:
http://minima-mirror-ci-bv.mgr.suse.de/SUSE/Products/MultiLinuxManagerTools/RES-7/x86_64/product/x86_64/

Ubuntu and debian approach :
Currently, only one tool repository is added for Debian. Should we add the release update repository by default as well?

I followed the SUSE pattern and added it. Is this correct?

Example for 5.0:

Before:

http://minima-mirror-ci-bv.mgr.suse.de/ibs/Devel:/Galaxy:/Manager:/5.0:/Ubuntu22.04-SUSE-Manager-Tools/xUbuntu_22.04

After

http://minima-mirror-ci-bv.mgr.suse.de/SUSE/Updates/Ubuntu/22.04-CLIENT-TOOLS/x86_64/update/
http://minima-mirror-ci-bv.mgr.suse.de/ibs/Devel:/Galaxy:/Manager:/5.0:/Ubuntu22.04-SUSE-Manager-Tools/xUbuntu_22.04

Additional repository for slmicro in uyuni

In Uyuni, all repositories use the systemsmanagement: namespace except the tools_additional_repo for SLEMicro6. Should this be kept or removed?

tools_additional_repo:
  pkgrepo.managed:
    - baseurl: http://{{ grains.get("mirror") | default("dist.nue.suse.com", true) }}/ibs/Devel:/Galaxy:/Manager:/Head:/SL-Micro-6-SUSE-Manager-Tools/SL-Micro6/
    - refresh: True

Salt Shaker (no product version):
This case is quite unclear — current repos are a mix of SUMA and Uyuni. What should Salt Shaker use? SUMA, MLM, or Uyuni? Pool and update? Just pool?

Example for alma8:

[root@suma-continuous-bv-alma8-minion ~]# cat /etc/yum.repos.d/tools_pool_repo.repo
# Created by cloud-init on Thu, 26 Jun 2025 22:39:24 +0000
[tools_pool_repo]
baseurl = http://minima-mirror-ci-bv.mgr.suse.de/repositories/systemsmanagement:/Uyuni:/Stable:/EL8-Uyuni-Client-Tools/EL_8/
enabled = 1
gpgcheck = 0
name = tools_pool_repo

[root@suma-continuous-bv-alma8-minion ~]# cat /etc/yum.repos.d/tools_update_repo.repo
[tools_update_repo]
baseurl=http://minima-mirror-ci-bv.mgr.suse.de/SUSE/Updates/RES/8-CLIENT-TOOLS/x86_64/update/
refresh=1
name=tools_update_repo
enabled=1

Verify SLEMicro Repositories for All Product Versions

Testing repositories extraction

To verify the changes, I deployed most paths (except 4.3/client) and extracted the repolist.
Directories with old prefixes were deployed with the current client_tools.sls, and new prefixes were deployed using the split version.

I couldn't make sense of the Salt Shaker usage, so I defaulted to the SUMA version for it — though they might not even be needed.
repositories_test.zip

salt/repos/client_tools/client_tools_new_naming.sls

salt/repos/client_tools/init.sls

salt/repos/client_tools/client_tools_old_naming.sls

Bischoff

see nitpick

salt/repos/client_tools/client_tools_mlm.sls

deneb-alpha · 2025-07-24T21:08:39Z

@maximenoel8 finally I'm getting there....

Verification from releng

Release repositories for 5.1

Should they be:

/SUSE/Updates/MultiLinuxManagerTools/MultiLinuxManagerTools => client , or

/SUSE/Updates/<Client>/MultiLinuxManagerTools ? (this one is empty for debian / ubuntu)
I’ve used the first option.

All the client tools, with the exception of Debian/Ubuntu and SL Micro 6 use a Pool (AKA Products) and an Updates repo.
Debian and Ubuntu use ONLY the Updates repo.
SL Micro 6 ONLY use the Pool (AKA Products).
You can find all the clients under:

/SUSE/Products/MultiLinuxManagerTools/
/SUSE/Updates/MultiLinuxManagerTools/

For RHEL on suma

Should we add the release update RHEL repositories by default for all clients?
This seems done for MLM and partially for Salt Shaker (e.g., using Uyuni stable for pool and EL9 update for update).
Example for alma9 on 5.0
New version will be:
tools_pool_repo : http://minima-mirror-ci-bv.mgr.suse.de/SUSE/Products/EL/9-CLIENT-TOOLS/x86_64/product/
tools_update_repo : http://minima-mirror-ci-bv.mgr.suse.de/SUSE/Updates/EL/9-CLIENT-TOOLS/x86_64/update/
tools_additional_repo : http://minima-mirror-ci-bv.mgr.suse.de/ibs/Devel:/Galaxy:/Manager:/5.0:/EL9-SUSE-Manager-Tools/SUSE_EL-9_Update_standard/

The example you are mentioning is for 5.0, not for 5.1 but in 5.0/4.3 context, I didn't change anything. What you have used in the past is still valid. Just a note, also there the client tools are all providing a Pool (AKA Products) and an Updates repo, with again Debian and Ubuntu only using Updates and SL Micro 6 only using Pool (AKA Products) . What I changed in 5.1 is the naming schema, trying to follow some naming convention that before have been done a bit randomly.
I don't know what you mean with using Uyuni stable for pool and EL9 update for update. I fear we are a bit "lost in jargon" here.

Verify repositories for slmicro6 for mlm

Please verify the nightly and head repository paths.

I'll do it in the PR

RES8 channel moved to EL8 for 5.1.

It appears to have moved to EL8 for 5.1.

yes. As mentioned before I tried to call all the RH clones EL followed by the version number. At least, wherever possible and where I had flexibility from autobuild team about the naming. In some cases this attempt to harmonize the naming was not possible.

RES7 Channel:

There's an inconsistency between RES7 and EL7 usage in release vs. devel:

http://dist.nue.suse.com/ibs/Devel:/Galaxy:/Manager:/5.1:/MLMTools-EL7/images/repo/ManagerTools-EL7-POOL-x86_64-Media/  
vs  
http://minima-mirror-ci-bv.mgr.suse.de/SUSE/Products/MultiLinuxManagerTools/RES-7/

this is one of the cases where I hit a wall in the attempt to harmonize the names. Also, I tried to shorten the name in our devel projects, using the acronym MLM, that can NOT be used in the official repositories.
Also, for really old products like RES7, the way to build and define the product is done using an old style/definition/product builder and I can't do too much magic.

In general, our devel projects under Devel:Galaxy:Manager are now following this naming convention for 5.1 and Head:

5.1: Devel:Galaxy:Manager:5.1:MLMTools- followed by the name of the OS.
- Devel:Galaxy:Manager:5.1:MLMTools-Debian12
- Devel:Galaxy:Manager:5.1:MLMTools-EL7
- Devel:Galaxy:Manager:5.1:MLMTools-EL8
- Devel:Galaxy:Manager:5.1:MLMTools-EL9
- Devel:Galaxy:Manager:5.1:MLMTools-SLE12
- Devel:Galaxy:Manager:5.1:MLMTools-SLE12:SaltBundle
- Devel:Galaxy:Manager:5.1:MLMTools-SLE15
- Devel:Galaxy:Manager:5.1:MLMTools-SLE15:SaltBundle
- Devel:Galaxy:Manager:5.1:MLMTools-SL-Micro-6
- Devel:Galaxy:Manager:5.1:MLMTools-Ubuntu22.04
- Devel:Galaxy:Manager:5.1:MLMTools-Ubuntu24.04
Head: Devel:Galaxy:Manager:Head:MLMTools-Beta- followed by the name of the OS.
- Devel:Galaxy:Manager:Head:MLMTools-Beta-Debian12
- Devel:Galaxy:Manager:Head:MLMTools-Beta-EL7
- Devel:Galaxy:Manager:Head:MLMTools-Beta-EL8
- Devel:Galaxy:Manager:Head:MLMTools-Beta-EL9
- Devel:Galaxy:Manager:Head:MLMTools-Beta-SLE12
- Devel:Galaxy:Manager:Head:MLMTools-Beta-SLE12:SaltBundle
- Devel:Galaxy:Manager:Head:MLMTools-Beta-SLE15
- Devel:Galaxy:Manager:Head:MLMTools-Beta-SLE15:SaltBundle
- Devel:Galaxy:Manager:Head:MLMTools-Beta-SL-Micro-6
- Devel:Galaxy:Manager:Head:MLMTools-Beta-Ubuntu22.04
- Devel:Galaxy:Manager:Head:MLMTools-Beta-Ubuntu24.04

5.0 and 4.3 are unchanged.

How to use RCE repository in product ?

Current 5.0-nightly:
http://minima-mirror-ci-bv.mgr.suse.de/repo/$RCE/RES7-SUSE-Manager-Tools/x86_64/
http://minima-mirror-ci-bv.mgr.suse.de/ibs/Devel:/Galaxy:/Manager:/5.0:/RES7-SUSE-Manager-Tools/SUSE_RES-7_Update_standard/
Current 5.1-nightly:
http://minima-mirror-ci-bv.mgr.suse.de/SUSE/Products/MultiLinuxManagerTools/RES-7/x86_64/product/x86_64/

5.0 is unchanged, in 5.1 I managed to get rid of that weird $RCE and the repos are the ones I shared before.

Ubuntu and debian approach :

Currently, only one tool repository is added for Debian. Should we add the release update repository by default as well?

I followed the SUSE pattern and added it. Is this correct?

If you add both you get different content. Looking at the example you shared, not sure what's the final goal.

Example for 5.0:

Before:

http://minima-mirror-ci-bv.mgr.suse.de/ibs/Devel:/Galaxy:/Manager:/5.0:/Ubuntu22.04-SUSE-Manager-Tools/xUbuntu_22.04

this is the devel content coming from our devel projects (it's what I think you call nightly).

After

http://minima-mirror-ci-bv.mgr.suse.de/SUSE/Updates/Ubuntu/22.04-CLIENT-TOOLS/x86_64/update/
http://minima-mirror-ci-bv.mgr.suse.de/ibs/Devel:/Galaxy:/Manager:/5.0:/Ubuntu22.04-SUSE-Manager-Tools/xUbuntu_22.04

this is the devel content coming from our devel projects plus the released content. The result is a mix of all the updates released to customers (stable) plus our nightly changes.

Additional repository for slmicro in uyuni

In Uyuni, all repositories use the systemsmanagement: namespace except the tools_additional_repo for SLEMicro6. Should this be kept or removed?
tools_additional_repo:
  pkgrepo.managed:
    - baseurl: http://{{ grains.get("mirror") | default("dist.nue.suse.com", true) }}/ibs/Devel:/Galaxy:/Manager:/Head:/SL-Micro-6-SUSE-Manager-Tools/SL-Micro6/
    - refresh: True

I'm confused. Uyuni can't use any content coming from IBS. If you need content from IBS like ibs/Devel:/Galaxy:/Manager:/Head something is deeply wrong.

Salt Shaker (no product version):

This case is quite unclear — current repos are a mix of SUMA and Uyuni. What should Salt Shaker use? SUMA, MLM, or Uyuni? Pool and update? Just pool?

Example for alma8:

[root@suma-continuous-bv-alma8-minion ~]# cat /etc/yum.repos.d/tools_pool_repo.repo
# Created by cloud-init on Thu, 26 Jun 2025 22:39:24 +0000
[tools_pool_repo]
baseurl = http://minima-mirror-ci-bv.mgr.suse.de/repositories/systemsmanagement:/Uyuni:/Stable:/EL8-Uyuni-Client-Tools/EL_8/
enabled = 1
gpgcheck = 0
name = tools_pool_repo

[root@suma-continuous-bv-alma8-minion ~]# cat /etc/yum.repos.d/tools_update_repo.repo
[tools_update_repo]
baseurl=http://minima-mirror-ci-bv.mgr.suse.de/SUSE/Updates/RES/8-CLIENT-TOOLS/x86_64/update/
refresh=1
name=tools_update_repo
enabled=1

Salt shaker is our of releng domain. It's the ION squad using it. I can help with some repos if they ask, but I'm really not using it at all and I can't help you here.

Verify SLEMicro Repositories for All Product Versions

I'll do it in the PR

salt/repos/client_tools/client_tools_suma.sls

salt/repos/client_tools/client_tools_uyuni.sls

maximenoel8 · 2025-07-25T01:12:09Z

I will try to create a review task here to see if it's correct.
Excluding debian and ubuntu

Release repositories (Updates and Products) for all products are correct
Development repositories (nightly) for all products are correct
Head repositories for all products are correct
Removing RCE for 5.1 is correct

What is not correct:

ubuntu and debian definitions
ibs repository in uyuni -> fixed
salt shaker unknown
head repos in 5.1 and 4.3 product -> fixed

maximenoel8 · 2025-07-25T01:22:30Z

For uyuni definition (point 8)
I strongly believe we had an issue in the current definition with the tools_additional_repo:
We probably made a mistake with the if.
It has not impact on the current deployments because we don't test or use slmicro in uyuni.
I will remove the repository.

maximenoel8 · 2025-07-25T01:42:45Z

For Ubuntu and Debian approach (point 7). Probably also relevant for RHEL minion (point 2).

This mix of release repositories and development repositories is done for all the products.
Example for sles15sp5 deployment using 5.0-nightly product version from our current client tools:

http://minima-mirror-ci-bv.mgr.suse.de/SUSE/Products/SLE-Module-Basesystem/15-SP5/x86_64/product/
http://minima-mirror-ci-bv.mgr.suse.de/SUSE/Updates/SLE-Module-Basesystem/15-SP5/x86_64/update/
http://minima-mirror-ci-bv.mgr.suse.de/repositories/systemsmanagement:/Uyuni:/Test-Packages:/Pool/rpm/
http://minima-mirror-ci-bv.mgr.suse.de/ibs/Devel:/Galaxy:/Manager:/5.0:/SLE15-SUSE-Manager-Tools/images/repo/SLE-15-Manager-Tools-POOL-x86_64-Media1/
http://minima-mirror-ci-bv.mgr.suse.de/SUSE/Products/SLE-Manager-Tools/15/x86_64/product/
http://minima-mirror-ci-bv.mgr.suse.de/SUSE/Updates/SLE-Manager-Tools/15/x86_64/update/

I extracted all those repositories depending on version during my testing. There are available here.

I was just doing a current state analysis and don't have the full history.

I wanted to harmonize this setup to ubuntu and debian. My reasoning is, release repository is what is available and adding the development repositories is to get access to new version. That's what we are actually doing with BV.

But I maybe wrong and so the question are:

should we only use the development repository for X-nightly and by consequence remove all the release repositories when running nightly (this will completely change all the configurations and mean we are currently testing with the wrong repositories)
is debian and ubuntu the exceptions and should not have the release update repository ?
or all products should have the release repository (currently in the PR)

When I refactor the rhel and deb-like block, the definition was complex and I assume some errors.

maximenoel8 requested a review from a team as a code owner June 24, 2025 03:11

maximenoel8 self-assigned this Jun 24, 2025

maximenoel8 marked this pull request as draft June 24, 2025 03:11

maximenoel8 changed the title ~~Split client tools file~~ WP: Split client tools file Jun 24, 2025

maximenoel8 force-pushed the split_client_tools branch 2 times, most recently from fcaa994 to 20737f2 Compare June 24, 2025 03:44

maximenoel8 mentioned this pull request Jun 24, 2025

Fix RedHat tools pool #1861

Merged

maximenoel8 force-pushed the split_client_tools branch from d003832 to 859d447 Compare June 24, 2025 21:17

srbarrios reviewed Jun 26, 2025

View reviewed changes

salt/repos/client_tools/client_tools_new_naming.sls Outdated Show resolved Hide resolved

srbarrios reviewed Jun 26, 2025

View reviewed changes

salt/repos/client_tools/init.sls Show resolved Hide resolved

srbarrios reviewed Jun 26, 2025

View reviewed changes

salt/repos/client_tools/client_tools_old_naming.sls Outdated Show resolved Hide resolved

maximenoel8 requested review from a team and deneb-alpha June 27, 2025 00:00

maximenoel8 assigned raulillo82 and unassigned raulillo82 Jun 27, 2025

maximenoel8 changed the title ~~WP: Split client tools file~~ Split client tools file Jun 27, 2025

maximenoel8 marked this pull request as ready for review June 27, 2025 00:03

maximenoel8 unassigned raulillo82 Jun 27, 2025

maximenoel8 requested a review from raulillo82 June 27, 2025 00:34

Bischoff approved these changes Jun 27, 2025

View reviewed changes

salt/repos/client_tools/client_tools_mlm.sls Outdated Show resolved Hide resolved

maximenoel8 force-pushed the split_client_tools branch from fa7953e to 1bf8052 Compare June 30, 2025 22:01

ktsamis approved these changes Jul 2, 2025

View reviewed changes

Split client tools into three files. uyuni, suma and mlm

615fac0

maximenoel8 force-pushed the split_client_tools branch from 1bf8052 to 615fac0 Compare July 23, 2025 08:26

deneb-alpha reviewed Jul 24, 2025

View reviewed changes

salt/repos/client_tools/client_tools_suma.sls Outdated Show resolved Hide resolved

deneb-alpha reviewed Jul 24, 2025

View reviewed changes

salt/repos/client_tools/client_tools_uyuni.sls Outdated Show resolved Hide resolved

Remove head repository from 4.3, 5.0 and uyuni

2cc0c62

Bischoff merged commit baaa2f3 into uyuni-project:master Aug 1, 2025
2 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Split client tools file #1859

Split client tools file #1859

Uh oh!

maximenoel8 commented Jun 24, 2025 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Bischoff left a comment

Uh oh!

Uh oh!

deneb-alpha commented Jul 24, 2025 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

maximenoel8 commented Jul 25, 2025 •

edited

Loading

Uh oh!

maximenoel8 commented Jul 25, 2025

Uh oh!

maximenoel8 commented Jul 25, 2025 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

Split client tools file #1859

Split client tools file #1859

Uh oh!

Conversation

maximenoel8 commented Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR change?

Approach

Examples

Related issue

Verification needed by releng

Testing repositories extraction

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Bischoff left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

deneb-alpha commented Jul 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Verification from releng

Uh oh!

Uh oh!

Uh oh!

maximenoel8 commented Jul 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

maximenoel8 commented Jul 25, 2025

Uh oh!

maximenoel8 commented Jul 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

maximenoel8 commented Jun 24, 2025 •

edited

Loading

deneb-alpha commented Jul 24, 2025 •

edited

Loading

maximenoel8 commented Jul 25, 2025 •

edited

Loading

maximenoel8 commented Jul 25, 2025 •

edited

Loading