action #152092
Updated by okurz 4 months ago
## Motivation
See lessons learned meeting #139136. We just have to accept that there are situations where we need to run downgraded packages as OS bug workarounds but maybe our process for that is lacking. Unless we want to use SUSE Manager likely we should put all those downgrade handling in salt as we already do/did for other cases. So check what we currently have for handling in salt and extend that and document, reference in our process documentation
## Acceptance criteria
* **AC1:** All current package locks on OSD salt machines are ensured to be applied on machines by salt
* **AC2:** Our process documentation includes instructions how to handle downgraded packages
* **AC3:** It is still fine if we temporarily downgrade some packages, e.g. for bisecting or testing for some hours/days
## Suggestions
* First see #150965 and https://gitlab.suse.de/openqa/salt-states-openqa/-/merge_requests/1065 so if we apply zypper locks with the right comment then updating the system should still work
* Also potentially consider to bring Bring back https://gitlab.suse.de/openqa/salt-states-openqa/-/merge_requests/984 in a general way
* Extend our salt recipes to track a list of downgraded packages and reasons, e.g.
* a list in salt pillars, applicable for certain roles, e.g. "all ppc64le osd openQA workers"
* according handling in salt states to install the specified downgraded package versions
* according zypper lock to prevent upgrades again with according zypper lock comment
* Extend our process documentation includes instructions how to handle downgraded packages, like simply write in the https://gitlab.suse.de/openqa/salt-states-openqa README how to downgrade and apply package locks properly packages
Back