action #125594
closed
- Description updated (diff)
- Status changed from New to Workable
- Target version set to Current
- Parent task set to #121864
- Status changed from Workable to In Progress
- Assignee set to zoecao
For this ticket the main goal is not refactor or split things, but make things so clear that someone without knowledge of migration could understand the steps, just checking openQA.
So it is very important, naming, visualization and for example share with the squad several times when you have done 1 or 2 split to get feedback.
Based on the testing steps, I split it to the following test modules:
- migration_setup: including disable installation repos
- register_origin_system: to register the origin system
- patch_system: including patch system, reboot and install required patterns, for example patterns of pcm.
- remove_dropped_modules: for example deregister ltss, python2 module
- deregistration_system: scheduled for media cases.
PR for this ticket:
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/16737
Looking at the ticket and the PR makes me ask some questions. If I understand this correctly, this ticket should be part of a bigger task that migrates from patch_sle to a set of modules. So at the end we would need to adapt all YAML schedules that use update/patch_sle (found 14 of them) and maybe also do something about main.pm which also schedules this module by loadtest 'update/patch_sle'; when no YAML file is there. Are we planning to remove the old patch_sle sooner or later in that process?
rainerkoenig wrote:
Looking at the ticket and the PR makes me ask some questions. If I understand this correctly, this ticket should be part of a bigger task that migrates from patch_sle to a set of modules. So at the end we would need to adapt all YAML schedules that use update/patch_sle (found 14 of them) and maybe also do something about main.pm which also schedules this module by loadtest 'update/patch_sle'; when no YAML file is there. Are we planning to remove the old patch_sle sooner or later in that process?
I don't know the whole plan for patch_sle. And yes you are right, if we remove it, then we need to update the main.pm and adapt all YAMLs which scheduled the update/patch_sle. And updating main.pm is complicated.
If we don't remove patch_sle, then we can use YAML to schedule the modules for migration cases.
rainerkoenig wrote:
Looking at the ticket and the PR makes me ask some questions. If I understand this correctly, this ticket should be part of a bigger task that migrates from patch_sle to a set of modules. So at the end we would need to adapt all YAML schedules that use update/patch_sle (found 14 of them) and maybe also do something about main.pm which also schedules this module by loadtest 'update/patch_sle'; when no YAML file is there. Are we planning to remove the old patch_sle sooner or later in that process?
From my point of view, this ticket should update main.pm and yaml schedule together, run enough VRs and update PR then let more related people to review, no hurry. :)
This is the current status of this ticket, split patch_sle to following test modules.
- migration_setup: including disable installation repos
- register_origin_system: to register the origin system
- patch_system: including patch system, reboot and install required patterns, for example patterns of pcm.
- remove_dropped_modules: for example deregister ltss, python2 module
- deregistration_system: scheduled for media cases.
This is the PR for this ticket:
PR for this ticket: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/16737
And as we discussed in meeting, I'll add a test suite (using the test modules above) to Migration:Dev job group.
- Priority changed from Normal to Low
@zoecao, As we talked offline, you will update the status when solved the VR issue and currently no enough time for it. That's fine, just please update the status in time so that others would know what you are doing for the ticket.
- Status changed from In Progress to Resolved
The PR and MR are merged, close here, thanks.
Also available in: Atom
PDF