action #30274

isos post sometimes trigger iso_cancel for whole product

Added by asmorodskyi about 2 years ago. Updated 6 months ago.

Status:ResolvedStart date:12/01/2018
Priority:NormalDue date:
Assignee:Xiaojing_liu% Done:

0%

Category:Feature requests
Target version:Current Sprint
Difficulty:
Duration:

Description

this event was not directly triggered
https://openqa.suse.de/admin/auditlog?eventid=928340
most probably it is consequence of doing isos post

So, when I did following call:

client isos post ARCH=x86_64 DISTRI=sle FLAVOR=Installer-DVD VERSION=15 ISO=SLE-15-Installer-DVD-x86_64-Build418.3-Media1.iso BUILD=418.3 TEST=autoyast_multipath --host https://openqa.suse.de

In the audit logs of openQA I got an entry with my name:
7 minutes ago riafarov iso_cancel { "VERSION": "15", "FLAVOR": "Installer-DVD", "ARCH": "x86_64", "DISTRI": "sle" }

Even though I haven't called cancel explicitly. So, it looks like client wanted to obsolete the run, but instead of single test suite, it has canceled all of them for defined medium.

As a workaround one can use _NOOBSOLETEBUILD=1 option not to obsolete jobs, which should help.


Related issues

Related to openQA Project - action #10316: [epic] Better command line options extending "client" In Progress 27/03/2018

History

#1 Updated by riafarov about 2 years ago

  • Description updated (diff)

#2 Updated by coolo about 2 years ago

  • Subject changed from [tools] isos post sometimes trigger iso_cancel for whole product to isos post sometimes trigger iso_cancel for whole product
  • Category set to Feature requests
  • Priority changed from Urgent to Normal
  • Target version set to Ready

This is not urgent as there is a workaround. And this has been the case forever - when TEST= support was implemented, it was never considered to be a shot afterwards

#3 Updated by okurz about 2 years ago

  • Related to action #10316: [epic] Better command line options extending "client" added

#4 Updated by okurz about 2 years ago

I think everything works as designed so even calling the use of the no-obsolete variable a "workaround" is maybe not appropriate.

Albeit I think that the default behaviour of "isos post" could be made more "safe" as in do not cancel any existing tests by default. So basically turn the default around and make "OBSOLETION" an optional feature that can be requested with an according parameter.

#5 Updated by mkittler over 1 year ago

So not a bug after all and just a bad default? Changing the default would be a breaking API change (even though in the direction of "being safer").

#6 Updated by okurz over 1 year ago

yes to all, still, if you could provide a PR to do this I guess we can go forward

#7 Updated by Xiaojing_liu 8 months ago

  • Status changed from New to In Progress
  • Assignee set to Xiaojing_liu

#9 Updated by coolo 7 months ago

  • Target version changed from Ready to Current Sprint

#10 Updated by Xiaojing_liu 7 months ago

  • Status changed from In Progress to Feedback

#11 Updated by Xiaojing_liu 6 months ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF