action #157873
openMerge vars HDDVERSION,FROM_VERSION and ORIGIN_SYSTEM_VERSION
0%
Description
Scope¶
Currently we are using three different variables HDDVERSION,FROM_VERSION and ORIGIN_SYSTEM_VERSION to describe the same thing. For MU slem tests TARGET_VERSION is used instead of VERSION and VERSION is used instead of ORIGIN_SYSTEM_VERSION.
We should decide on which of these to keep and replace other vars accordingly. This can be tricky as the vars are not only used in the yaml Job groups but in the openqa code as well.
Acceptance Criteria¶
- Discuss with the team or create poll to decide which name to keep (I would go with HDDVERSION)
- Replace the rest of the var names with the name of choice
- Modify openqa code accordingly for our tests and run VRs.
- Notify other teams that might use the modified code so that they rename their vars in their job group settings
Note: Might worth pinging SAP team as they also use migration with ORIGIN_SYSTEM_VERSION and UPGRADE_TARGET_VERSION. See test: https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Server-DVD-HA-Updates&machine=64bit&test=qam_ha_rolling_upgrade_migration_node01&version=15-SP4
Updated by JERiveraMoya 11 days ago
Variable should be called similarly to the ones offered by openQA, so they are easy to locate.
VERSION_ORIGIN & VERSION_TARGET, for migration to latest product or migration with unreleased maintenance updates (wumu) in the origin product we will use the first, and we only use the second for migration wumu in target. Make sense?
My plan from long ago is to make more clear/refactored the migration in maintenance and later tackle product, so we can narrow this task to maintenance for now for example. Could you add some examples to the ticket description based on what we have in maintenance after merging first migrations.
Updated by JERiveraMoya 9 days ago ยท Edited
Thinking twice, VERSION_2 might be a better candidate if we don't need to differentiate origin and target as the logic will be run by YAML schedule (2 = secondary version)
I created this one #159198 and we can visit this later for the bigger picture, because changing this in product validation might be too much scope.
Updated by syrianidou_sofia 9 days ago
JERiveraMoya wrote in #note-4:
Variable should be called similarly to the ones offered by openQA, so they are easy to locate.
VERSION_ORIGIN & VERSION_TARGET, for migration to latest product or migration with unreleased maintenance updates (wumu) in the origin product we will use the first, and we only use the second for migration wumu in target. Make sense?My plan from long ago is to make more clear/refactored the migration in maintenance and later tackle product, so we can narrow this task to maintenance for now for example. Could you add some examples to the ticket description based on what we have in maintenance after merging first migrations.
I think we should go for all together. Especially, SLM that the test number is currently small. If the task seems too big, the person who picks up, can open follow up tickets. For example create a draft for os-autoinst-distri-opensuse that will take care of any excess VARs in test modules, another ticket for replacing the excess VARs in our gitlab job group repo etc. It is a task that needs consistency to avoid breakage. If there are still different VARs, we might not be able to apply the desired changes os-autoinst-distri-opensuse and that increases complexity unnecessarily.
The examples are easily found by greping e.g. "TARGET_VERSION" ,"HDDVERSION"... in the repos