Project

General

Profile

Actions

action #152731

closed

coordination #151816: [epic] Handle openQA fixes and job group setup

Need create yaml schedule file for offline media continuous migration test

Added by leli 10 months ago. Updated 9 months ago.

Status:
Resolved
Priority:
Normal
Target version:
-
Start date:
2023-12-18
Due date:
% Done:

0%

Estimated time:

Description

Motivation:
Failed job
This incomplete test failed for the previous job hasn't published qcow, and the yaml schdule file in https://openqa.suse.de/tests/13005419# need update to support media continuous migration test.

Acceptance criteria:
AC1: Need create yaml schedule file for offline media continuous migration test

Actions #1

Updated by JERiveraMoya 10 months ago

  • Tags set to qe-yam-dec-sprint
  • Status changed from New to Workable
  • Parent task set to #151816
Actions #2

Updated by syrianidou_sofia 10 months ago

  • Status changed from Workable to In Progress
  • Assignee set to syrianidou_sofia
Actions #3

Updated by JERiveraMoya 9 months ago

  • Tags changed from qe-yam-dec-sprint, qe-yam-jan-sprint to qe-yam-jan-sprint
Actions #4

Updated by syrianidou_sofia 9 months ago · Edited

The schedule was there but seems like some runs were set to use wrong name of the schedule. Fixed the contitions so that uploading of the hdd happens with or without deregistration:
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18382
https://openqa.suse.de/tests/13179339

Actions #5

Updated by leli 9 months ago · Edited

syrianidou_sofia wrote in #note-4:

The schedule was there but seems like some runs were set to use wrong name of the schedule. Fixed the contitions so that uploading of the hdd happens with or without deregistration:
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18382
https://openqa.suse.de/tests/13179339

The continuous migration test has two phases, we would like to re-use the schedule for both phases so the schedule file should cover with or without publishing qcow(phase0 will publish qcow for phase1 to run migration test, while phase1 don't need publish qcow). The current schedule file with scc_deregistration which is not needed for media migration. So one condition SCC_DEREGISTER is not enough, the easy way to fix it is to create a new yaml file for media migration without the scc_deregistration.

Actions #6

Updated by syrianidou_sofia 9 months ago

leli wrote in #note-5:

syrianidou_sofia wrote in #note-4:

The schedule was there but seems like some runs were set to use wrong name of the schedule. Fixed the contitions so that uploading of the hdd happens with or without deregistration:
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18382
https://openqa.suse.de/tests/13179339

The continuous migration test has two phases, we would like to re-use the schedule for both phases so the schedule file should cover with or without publishing qcow(phase0 will publish qcow for phase1 to run migration test, while phase1 don't need publish qcow). The current schedule file with scc_deregistration which is not needed for media migration. So one condition SCC_DEREGISTER is not enough, the easy way to fix it is to create a new yaml file for media migration without the scc_deregistration.

The svirt_upload module will not upload anything if there is no PUBLISH_HDD variable set, see here: https://openqa.suse.de/tests/13186558#step/svirt_upload_assets/4
But the two tests have quite different schedule, I don't see how we can use one file, unless we put a bunch of conditions inside, which is not a good practice.

Actions #7

Updated by leli 9 months ago

syrianidou_sofia wrote in #note-6:

leli wrote in #note-5:

syrianidou_sofia wrote in #note-4:

The schedule was there but seems like some runs were set to use wrong name of the schedule. Fixed the contitions so that uploading of the hdd happens with or without deregistration:
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18382
https://openqa.suse.de/tests/13179339

The continuous migration test has two phases, we would like to re-use the schedule for both phases so the schedule file should cover with or without publishing qcow(phase0 will publish qcow for phase1 to run migration test, while phase1 don't need publish qcow). The current schedule file with scc_deregistration which is not needed for media migration. So one condition SCC_DEREGISTER is not enough, the easy way to fix it is to create a new yaml file for media migration without the scc_deregistration.

The svirt_upload module will not upload anything if there is no PUBLISH_HDD variable set, see here: https://openqa.suse.de/tests/13186558#step/svirt_upload_assets/4
But the two tests have quite different schedule, I don't see how we can use one file, unless we put a bunch of conditions inside, which is not a good practice.

That's why I suggest to create a new yaml schedule file for media migration test to avoid to add more conditions to this schedule file.

Actions #8

Updated by syrianidou_sofia 9 months ago

leli wrote in #note-7:

syrianidou_sofia wrote in #note-6:

leli wrote in #note-5:

syrianidou_sofia wrote in #note-4:

The schedule was there but seems like some runs were set to use wrong name of the schedule. Fixed the contitions so that uploading of the hdd happens with or without deregistration:
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18382
https://openqa.suse.de/tests/13179339

The continuous migration test has two phases, we would like to re-use the schedule for both phases so the schedule file should cover with or without publishing qcow(phase0 will publish qcow for phase1 to run migration test, while phase1 don't need publish qcow). The current schedule file with scc_deregistration which is not needed for media migration. So one condition SCC_DEREGISTER is not enough, the easy way to fix it is to create a new yaml file for media migration without the scc_deregistration.

The svirt_upload module will not upload anything if there is no PUBLISH_HDD variable set, see here: https://openqa.suse.de/tests/13186558#step/svirt_upload_assets/4
But the two tests have quite different schedule, I don't see how we can use one file, unless we put a bunch of conditions inside, which is not a good practice.

That's why I suggest to create a new yaml schedule file for media migration test to avoid to add more conditions to this schedule file.

Sorry, I'm very confused. Which tests do you want to use the same schedule as the media migration test: offline_sle12sp5_sles15sp4_sles15sp_latest_media_all_full_s390x_ph0

Actions #9

Updated by leli 9 months ago · Edited

After discussed with Joaquin, we don't need to consider product for future, so don't need make the yaml schedule to suit two continuous migration phases. I merged the PR. Thanks.

Just one thing left, could you file a PR to do same update for yaml schedule files for other 3 arches?

-rw-r--r-- 1 root root 1440 Dec 14 13:49 migration_offline_scc_deregistration_aarch64.yaml
-rw-r--r-- 1 root root 1435 Dec 14 13:49 migration_offline_scc_deregistration_ppc64le.yaml
-rw-r--r-- 1 root root 1408 Dec 14 13:49 migration_offline_scc_deregistration_x86_64.yaml

Actions #11

Updated by syrianidou_sofia 9 months ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF