Re: Problem with salt states pushed to OES

Michael, Thanks! It sounds like you think the OES people should not be using such a method? I can query it with the product management people there... The issue here has been simply resolved for now by me with a minor modification to /usr/share/susemanager/salt/packages/init.sls but it's a crude solution because it relies on identifying an OES system by virtue of the fact that it's oscodename grain is 'SUSE Linux Enterprise Server 12 SP5' - so ancient that our OES servers are the only systems running this! So we can use it to identify OES It would be better to have a grain specifically identifying Open Enterprise Server - if anyone is listening... Pseudo code might be: if exists /etc/novell-release read version from file create grain for OES version Agreed - *-migration products should NOT be candidates for automatic installation - but I'm afraid I do not have the necessary skills to propose a modification to https://github.com/uyuni-project/uyuni/blob/master/susemanager-utils/suseman... But if suitably knowledgeable person contribute, it's a job worth doing! T *Please note I am now working part-time - Tuesdays and Wednesday only* ___________________________________________________________ TIM SHAW - MSD IT Systems & Network Services Medical Sciences Division - University of Oxford email : tim.shaw@medsci.ox.ac.uk tel : +44 (0)1865 289480

...

...

Michael Calmer 08/12/2021 14:41 >>> Hi

Hello

I think there is a problem with the way Uyuni works with Open Enterprise Server systems

On OES, when a Service Pack becomes available it is delivered as a zypper product which SHOULD remain uninstalled until such time as the Service Pack migration is initiated. Then as part of the migration the

We thought the time of migration products is over. Well, anyway. You can create a Content Live Management Project and filter the migration packages out. This would be a permanent solution. You can also manually change /usr/share/susemanager/salt/packages/init.sls This is the state which call the installation. And if you are really good, you can make a PR and fix the state module directly https://github.com/uyuni-project/uyuni/blob/master/susemanager-utils/suseman... ¶ I think the goal would be to remove all "*-migration" packages from the list. I hope it helps. Am Mittwoch, 8. Dezember 2021, 15:21:08 CET schrieb Tim Shaw: product is installed.

From what we can see Uyuni is ignoring this and blindly installing

the product if it sees it present but not installed. Se below from the event history on an OES2018SP2 system. The Open_Enterprise_Server-SP3-migration product is NOT supposed to be installed - just left available until a decision to upgrade is taken.

---------- ID: mgr_install_products Function:

product.installed Name: mgr_install_products Result: true Comment: 1 targeted package was installed/updated. Started: 09:09:31.882562 Duration: 12961.896 SLS: packages Changed: Open_Enterprise_Server-SP3-migration: new: 2018.2-3.1 old: ''

This is serious because it causes new repos for the new service pack

to be collected from the SUSE registration server and offered to the system - so you then get packages from the new Service Pack introduced to a system running the older service release

AAARRGGHH!!!

How can I sort this out - I'm assuming it is a bug...- but in the

meantime where can I find and disable this procedure?

T

*Please note I am now working part-time - Tuesdays and Wednesday

only*

___________________________________________________________ TIM SHAW - MSD IT Systems & Network Services Medical Sciences Division - University of Oxford email : tim.shaw@medsci.ox.ac.uk tel : +44 (0)1865 289480

-- Regards Michael Calmer -------------------------------------------------------------------------- Michael Calmer SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg T: +49 (0) 911 74053 0 F: +49 (0) 911 74053575 - e-mail: Michael.Calmer@suse.com -------------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, GF: Ivo Totev (HRB 36809, AG Nürnberg)