Project

General

Profile

action #30730

[tools] Improve behaviour of "isos post" when triggering a (sub)set of jobs with parent jobs (e.g. qcow creation jobs)

Added by mgriessmeier over 2 years ago. Updated 10 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Feature requests
Target version:
Start date:
2018-01-23
Due date:
% Done:

0%

Estimated time:
Difficulty:
Duration:

Description

User story

Right now I'm facing the issue that I want to retrigger a subset of jobs from one medium.

All of them are booting a HDD Image so they all have the variable START_AFTER_TEST=create_hdd_textmode set.

Since it is a retrigger of those because I had to change some variables in the webui, I don't want to trigger the parent creation job triggered again, since it already passed and the qcow image is present - but this is exactly what happens

This could be improved (e.g. checking if the qcow is already present) to reduce test-execution time and reducing chance of possible failures for other tests relying on that qcow image (e.g. when it gets newly published during another test runs)

Steps to "reproduce"

I have 3 jobs given, hpc_conman, hpc_powerman and hpc_hwloc which are in a job group called HPC and should be triggered for x86_64 and aarch64.
all three have in common

  • START_AFTER_TEST=create_hdd_textmode
  • BOOT_HDD_IMAGE=1
  • HDD_1=sle-%VERSION%-%ARCH%-%BUILD%-textmode@%MACHINE.qcow2

I change some settings in the webui to those jobs and execute following command from my local machine with the intention to trigger those three jobs for aarch64

usr/bin/openqa-client isos post --host openqa.suse.de DISTRI=sle VERSION=15 FLAVOR=Installer-DVD ARCH=aarch64 ISO=SLE-15-Installer-DVD-aarch64-Build422.1-Media1.iso BUILD=422.1 DESKTOP=textmode TEST=hpc_hwloc,hpc_conman,hpc_powerman 

what I get is

{ count => 4, failed => [], ids => [1410023 .. 1410026] }

crosschecking with openQA shows me that my three jobs were triggered along with "create_hdd_textmode@aarch64" - even though the HDD_1 which should be used was already present on o.s.d

I've did that several times today, because HPC jobgroup is more like a development job group right now (I know... we should have a dedicated group for that, but PO doesn't want to)
=> https://openqa.suse.de/tests/1410023#previous shows 5 runs for Build 422.1

I've tried two things to do the trick, but failed.

  • adding START_AFTER_TEST=0 to the isos post call leads to
    ´START_AFTER_TEST=0:aarch64 not found - check for typos and dependency cycles`

  • leaving it just blank with "START_AFTER_TEST=" was triggering the creation job as well

Acceptance Criteria

so in order to have this working I would consider following acceptance criterias

  • isos post can be used like it is now, with all the variables from the job and

    • either checks if the HDD_1 it should use does already exist and doesn't need to be created
    • or checks the state of the last execution of the parent job and only triggers it if that latest run failed

Related issues

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

History

#1 Updated by mgriessmeier over 2 years ago

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

#2 Updated by mgriessmeier over 2 years ago

  • Description updated (diff)

#3 Updated by coolo over 2 years ago

START_AFTER_TEST doesn't make sense for an iso. So what did you do exactly and what do you expect?

#4 Updated by mgriessmeier over 2 years ago

  • Description updated (diff)

#5 Updated by mgriessmeier over 2 years ago

  • Description updated (diff)

coolo wrote:

START_AFTER_TEST doesn't make sense for an iso. So what did you do exactly and what do you expect?

updated - hope it's clearer now

#6 Updated by okurz over 1 year ago

  • Subject changed from [tools] Improve behaviour of "isos post" when triggering a (sub)set of jobs with partent jobs (e.g. qcow creation jobs) to [tools] Improve behaviour of "isos post" when triggering a (sub)set of jobs with parent jobs (e.g. qcow creation jobs)

#7 Updated by okurz over 1 year ago

  • Description updated (diff)

#8 Updated by Xiaojing_liu about 1 year ago

  • Assignee set to Xiaojing_liu

#9 Updated by okurz about 1 year ago

  • Category changed from 122 to Feature requests

#10 Updated by coolo about 1 year ago

  • Target version set to Current Sprint

#11 Updated by Xiaojing_liu 12 months ago

mgriessmeier wrote:

coolo wrote:

START_AFTER_TEST doesn't make sense for an iso. So what did you do exactly and what do you expect?

updated - hope it's clearer now

As your description, I think you would like to re-trigger the test suite and not trigger its parent after you modified the test suite settings, right?

client isos post does not support this kind of operation for now. You could try client jobs post.

#12 Updated by okurz 12 months ago

Xiaojing_liu wrote:

As your description, I think you would like to re-trigger the test suite and not trigger its parent after you modified the test suite settings, right?
client isos post does not support this kind of operation for now.

It kinda does. To be exact, @Xiaojing_liu you wrote "to re-trigger the test suite": This isn't strictly possible. One can either spawn a new test job, either clean just based on supplied settings – client jobs post – or clone an existing job – web UI or openqa-clone-job – with optional overwrites of values or spawn multiple jobs based on the job templates defined by media, machines, test suites, job groups. By calling isos post with the same parameter as in before one effectively triggers clones.

You could try client jobs post.

This will not work because the cluster of jobs need to be triggered exactly together so that the scheduler ensures the job relation within the cluster.

I understand the requirement like this: "If one specifies the list of test scenarios explicitly then openQA should execute these and only these scenarios". In the above example three scenarios are mentioned but the parent is implicitly triggered but then with potentially wrong settings. So from a users perspective I guess same as the --skip-chained-deps parameter to "openqa-clone-job" one wants to have the same for clusters.

#13 Updated by Xiaojing_liu 12 months ago

I asked for some OpenQA users in Beijing office and got some responses about triggering/re-triggering jobs/test suites.

  1. re-trigger job using clone_job.pl

Almost all testers use clone_job.pl to re-trigger a job when they want to modify the job's setting.
Such as: /usr/share/openqa/script/clone_job.pl --from http://openqa.suse.de --host http://openqa.suse.de 2244563 --skip-download --apikey 631DFB4447121627 --apisecret 27D4A19274598018 BUILD=xxx ISO=xxxx

There is a suggestion:

a. the new setting value should be passed to dependency jobs (parent and parallel jobs). - Maybe we could provide a parameter to support this request. (--parental-inheritance could work for this request)
  1. trigger test suite(s) using 'client isos post'

There are some suggestions:

a. Sometimes users would like to trigger one or more test suites after they modify the test suites' setting in WebUI, they do not know the TEST argument. So users want an argument to support triggering one test suite.

b. When triggering the specified test suite(s), users do not want to trigger the parent test suite (For example the parent test suite is used to create a qcow file which has already been created. If the parent test suite does not be triggered, just validate the specified test suite, so it can save much time).  - just like this ticket has mentioned.

c. When triggering the specified test suite(s), the setting value should be re-defined in the command. ('client isos post' and 'clone_job.pl' have already supported this)

Nobody use 'client jobs post'.

According to above information, seems like the existed tools can handle almost all requests. For this ticket, maybe we should add a new parameter in 'client isos post' to distinguish if trigger the dependency jobs.

#14 Updated by mgriessmeier 12 months ago

Xiaojing_liu wrote:

According to above information, seems like the existed tools can handle almost all requests. For this ticket, maybe we should add a new parameter in 'client isos post' to distinguish if trigger the dependency jobs.

+1

#15 Updated by Xiaojing_liu 12 months ago

  • Status changed from New to Resolved

#16 Updated by Xiaojing_liu 12 months ago

  • Status changed from Resolved to In Progress

#18 Updated by Xiaojing_liu 11 months ago

  • Status changed from In Progress to Feedback

#19 Updated by Xiaojing_liu 10 months ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF