Project

General

Profile

Actions

action #90131

closed

don't obsolete jobs with the same build number in different job groups when using `_OBSOLETE`

Added by Xiaojing_liu over 3 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
Support
Target version:
Start date:
2021-03-16
Due date:
2021-04-01
% Done:

0%

Estimated time:

Description

User story

Users have different job groups, and the job groups have the same distri, version, arch, flavor. When a new build comes, the jobs belong to group A are triggered first. Then the jobs belong to group B are triggered and with parameter _OBSOLETE=1. This caused all jobs belong to group A are canceled.

Acceptance criteria

  • AC1: When using _OBSOLETE=1, only the jobs with older build number(different with the new one) and belong to same job group will be canceled.
Actions #1

Updated by okurz over 3 years ago

  • Assignee set to okurz
  • Priority changed from Normal to Low
  • Target version set to Ready

http://open.qa/docs/#_spawning_multiple_jobs_based_on_templates_isos_post already references available scheduling parameters, e.g. there is also _ONLY_OBSOLETE_SAME_BUILD which sounds like the opposite of what you describe.

What you describe with

When a new build comes, the jobs belong to group A are triggered first. Then the jobs belong to group B are triggered and with parameter _OBSOLETE=1

sounds more like a mistake done by a human operator or a bug. Can you describe the problem that happened in a bit more detail? What happens is very much dependant on what component triggers new builds. Is this based on observations from osd or another instance? What I assume should happen by default on osd is that new product builds are triggered with _DEPRIORITIZEBUILD and old builds should still have to chance to complete their tests.

Actions #2

Updated by Xiaojing_liu over 3 years ago

okurz wrote:

http://open.qa/docs/#_spawning_multiple_jobs_based_on_templates_isos_post already references available scheduling parameters, e.g. there is also _ONLY_OBSOLETE_SAME_BUILD which sounds like the opposite of what you describe.

Sorry, I didn't describe clearly. Users don't want to cancel the same build. They want to cancel the older build.

What you describe with

When a new build comes, the jobs belong to group A are triggered first. Then the jobs belong to group B are triggered and with parameter _OBSOLETE=1

sounds more like a mistake done by a human operator or a bug. Can you describe the problem that happened in a bit more detail? What happens is very much dependant on what component triggers new builds. Is this based on observations from osd or another instance? What I assume should happen by default on osd is that new product builds are triggered with _DEPRIORITIZEBUILD and old builds should still have to chance to complete their tests.

I will I invite one user to answer this question.

Actions #3

Updated by JNa over 3 years ago

The issue is found on our local Beijing openQA(10.67.129.4)
we have SPA-HANA and SLE-Performance job group.
1.when build 162.7 is coming,HANA trigger it's job firstly.
and performance is doing build161.1 testing.
2.Later performance trigger script found build162.7 is coming,so it's using isos post API with _OBSOLETE trigger new build.
3._OBSOLETE parameter cancel the performance build161.1 job ,

  1. and also cancel the HANA build162.7 job
  2. step 3 is what we want,but step 4 is not. so do you have any suggestion about how to spawning this jobs?
Actions #4

Updated by okurz over 3 years ago

  • Due date set to 2021-03-24
  • Category changed from Feature requests to Support
  • Status changed from New to Feedback

Xiaojing_liu wrote:

okurz wrote:

http://open.qa/docs/#_spawning_multiple_jobs_based_on_templates_isos_post already references available scheduling parameters, e.g. there is also _ONLY_OBSOLETE_SAME_BUILD which sounds like the opposite of what you describe.

Sorry, I didn't describe clearly. Users don't want to cancel the same build. They want to cancel the older build.

I know. I understood that. This is what I meant: There is already _ONLY_OBSOLETE_SAME_BUILD but what you describe sounds like the opposite is needed. So I wonder if this is a new feature that makes sense. The flag _ONLY_OBSOLETE_SAME_BUILD was introduced with https://github.com/os-autoinst/openQA/commit/16af146abceee0eb18ec11826e9803659c8f8f7c and it was not too complicated. Maybe adding a flag like _ONLY_OBSOLETE_OTHER_BUILDS would be not too hard to implement (in theory). However I currently would not plan to do that.

joyce wrote:

The issue is found on our local Beijing openQA(10.67.129.4)
we have SPA-HANA and SLE-Performance job group.
1.when build 162.7 is coming,HANA trigger it's job firstly.
and performance is doing build161.1 testing.
2.Later performance trigger script found build162.7 is coming,so it's using isos post API with _OBSOLETE trigger new build.
3._OBSOLETE parameter cancel the performance build161.1 job ,

  1. and also cancel the HANA build162.7 job
  2. step 3 is what we want,but step 4 is not. so do you have any suggestion about how to spawning this jobs?

Thanks for the example. I assume you trigger isos post with _OBSOLETE to cancel very long-running performance tests to run more recent tests on the same worker hardware. I think it might work to define the SAP-HANA tests as a separate product, e.g. change the medium parameters, so that the next isos post would not match the same parameters for SAP-HANA and performance tests. Please tell me if this works for you.

Actions #5

Updated by JNa over 3 years ago

okurz wrote:

Xiaojing_liu wrote:

okurz wrote:

http://open.qa/docs/#_spawning_multiple_jobs_based_on_templates_isos_post already references available scheduling parameters, e.g. there is also _ONLY_OBSOLETE_SAME_BUILD which sounds like the opposite of what you describe.

Sorry, I didn't describe clearly. Users don't want to cancel the same build. They want to cancel the older build.

I know. I understood that. This is what I meant: There is already _ONLY_OBSOLETE_SAME_BUILD but what you describe sounds like the opposite is needed. So I wonder if this is a new feature that makes sense. The flag _ONLY_OBSOLETE_SAME_BUILD was introduced with https://github.com/os-autoinst/openQA/commit/16af146abceee0eb18ec11826e9803659c8f8f7c and it was not too complicated. Maybe adding a flag like _ONLY_OBSOLETE_OTHER_BUILDS would be not too hard to implement (in theory). However I currently would not plan to do that.

joyce wrote:

The issue is found on our local Beijing openQA(10.67.129.4)
we have SPA-HANA and SLE-Performance job group.
1.when build 162.7 is coming,HANA trigger it's job firstly.
and performance is doing build161.1 testing.
2.Later performance trigger script found build162.7 is coming,so it's using isos post API with _OBSOLETE trigger new build.
3._OBSOLETE parameter cancel the performance build161.1 job ,

  1. and also cancel the HANA build162.7 job
  2. step 3 is what we want,but step 4 is not. so do you have any suggestion about how to spawning this jobs?

Thanks for the example. I assume you trigger isos post with _OBSOLETE to cancel very long-running performance tests to run more recent tests on the same worker hardware. I think it might work to define the SAP-HANA tests as a separate product, e.g. change the medium parameters, so that the next isos post would not match the same parameters for SAP-HANA and performance tests. Please tell me if this works for you.
Thanks for your suggestion,we will try to change FLAVOR when our testing enviroment is available.

Actions #6

Updated by livdywan over 3 years ago

  • Due date changed from 2021-03-24 to 2021-04-01

Moving up the due date due to hackweek

Actions #7

Updated by okurz over 3 years ago

  • Status changed from Feedback to Resolved

I added the idea of _ONLY_OBSOLETE_OTHER_BUILDS to #65271 and I hope the rest is sufficiently covered in this support ticket.

Actions

Also available in: Atom PDF