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 mc@suse.de 08/12/2021 14:41 >>>
Hi
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:
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 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
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 mc@suse.de 08/12/2021 14:41 >>>
Hi
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:
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 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
-
Tim Shaw