action #30730
closed[tools] Improve behaviour of "isos post" when triggering a (sub)set of jobs with parent jobs (e.g. qcow creation jobs)
0%
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
Updated by mgriessmeier over 6 years ago
- Related to coordination #10316: [epic] Better command line options extending "client" added
Updated by coolo over 6 years ago
START_AFTER_TEST doesn't make sense for an iso. So what did you do exactly and what do you expect?
Updated by mgriessmeier over 6 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
Updated by okurz about 5 years 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)
Updated by okurz almost 5 years ago
- Category changed from 122 to Feature requests
Updated by Xiaojing_liu almost 5 years 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.
Updated by okurz almost 5 years 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 postdoes 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.
Updated by Xiaojing_liu almost 5 years ago
I asked for some OpenQA users in Beijing office and got some responses about triggering/re-triggering jobs/test suites.
- 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)
- 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.
Updated by mgriessmeier almost 5 years 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
Updated by Xiaojing_liu almost 5 years ago
- Status changed from Resolved to In Progress
Updated by Xiaojing_liu over 4 years ago
Updated by Xiaojing_liu over 4 years ago
- Status changed from In Progress to Feedback
Updated by Xiaojing_liu over 4 years ago
- Status changed from Feedback to Resolved