action #162515
closedcoordination #161168: [epic] Support hooks for obs-sync plugin
[timeboxed:20h][spike solution] Adaptable product scheduling in openqa-trigger-from-obs size:S
0%
Description
Motivation¶
As findings in #161879#note-6 reveal, the change to make scheduling more dynamically needs to be done in openqa-trigger-from-obs
directly (as the openQA sync plugin is just a script runner and frontend). There are various ways to influence the job scheduling, e.g. adding support for invoking a hook script which could again be done on various levels/places. One could alter the script generator (scriptgen.py
) directly to change the generated scripts or one could alter rsync.sh
as shown in https://github.com/os-autoinst/openqa-trigger-from-obs/pull/249. It is also questionable whether we still want to top-level script generator (scriptgen.py
). The point is: There are many options to discuss/explore. If we just make it print "Hello world" somehow/somewhere as a first step this is not going to help us find what we need to solve the actual problem.
Acceptance criteria¶
- AC1: We know what we need to change in our current mechanism for triggering tests in the light of #159828.
- AC2: We know who (which team) is going to change what parts.
Suggestion¶
- Read #161879#note-6 and related source files to get an idea of how openqa-trigger-from-obs works
- Conduct a pair programming session with members from QE Core and QE Tools (or possibly other interested teams) to come up with a draft PR for https://github.com/os-autoinst/openqa-trigger-from-obs.
Updated by mkittler 4 months ago
We discussed this at the workshop. The actually identified 3 places where we could invoke the hook script:
rsync.sh
as my previous PR has already shown.- Inside the server-side scheduling logic of openQA. It could take another special parameter
HOOKSCRIPT=…
and run that script server-side. - By
openqa-cli
which could take another parameter--hook-script
and would call this script with all test variables specified on the command-line. The script can then amend this list of test variables beforeopenqa-cli
makes the actual API request.
Option 3. sounded the most promising.
Updated by ybonatakis 3 months ago
talk to Santi yesterday and from my understanding what he is looking for seeing at the moment is just that running the openqa-trigger-from-obs's script will just go through a set of other (hook) scripts which will expand the output (openqa-cli). Having said that, no condition are given for when the hook will apply. He thinks of this functionality behaving similar to git-hooks.
Updated by szarate 3 months ago
mkittler wrote in #note-3:
We discussed this at the workshop. The actually identified 3 places where we could invoke the hook script:
rsync.sh
as my previous PR has already shown.- Inside the server-side scheduling logic of openQA. It could take another special parameter
HOOKSCRIPT=…
and run that script server-side.- By
openqa-cli
which could take another parameter--hook-script
and would call this script with all test variables specified on the command-line. The script can then amend this list of test variables beforeopenqa-cli
makes the actual API request.Option 3. sounded the most promising.
option 3 sounds nice.
- while/when working on the implementation: remember you can always ask me
Updated by ybonatakis 3 months ago
- Status changed from Workable to In Progress
- Assignee set to ybonatakis
Updated by openqa_review 3 months ago
- Due date set to 2024-07-23
Setting due date based on mean cycle time of SUSE QE Tools
Updated by ybonatakis 3 months ago · Edited
What I tried today:
there is -D
option in openqa-cli (activated with -f
)
for example perl -I lib script/openqa-cli api -f -D ../hook/twdata.json --pretty --host http://127.0.0.1:9526 -X POST isos
where hook/twdata.json looks like
{
"ARCH":"x86_64",
"BACKEND":"qemu",
"BUILD":"newtw",
"DISTRI":"opensuse",
"FLAVOR":"NET",
"VERSION":"Tumbleweed",
"ISO":"openSUSE-Tumbleweed-NET-x86_64-Snapshot20240709-Media.iso",
"USBBOOT":"3"
}
I was thinking to extend lib/OpenQA/CLI/api.pm with --hook-scripts
which when it is set it will leverage this option + take data
from args to trigger custom jobs.
I didnt manage to implement anything so far.
Very likely, @szarate will have time tomorrow for a pair session.
Updated by ybonatakis 3 months ago
Updated by ybonatakis 3 months ago · Edited
Today at the programming session with @szarate we defined the interface and tested the idea.
The idea¶
Original call:¶
openqa-cli api --post-script-hook hook/awesome_scripts_set --host http://127.0.0.1:9526 -X POST isos BETA=1
Script post_foobar is called| it removed BETA=1¶
openqa-cli api --post-script-hook hook/awesome_scripts_set --host http://127.0.0.1:9526 -X POST isos FOO=BAR
Script post_hello_world is called | it added HELLO=WORLD¶
openqa-cli api --post-script-hook hook/awesome_scripts_set --host http://127.0.0.1:9526 -X POST isos FOO=BAR HELLO=WORLD
Invoke all together. Should be also possible¶
openqa-cli api --post-script-hook hook/awesome_scripts_set -f -D data.json --host http://127.0.0.1:9526 -X POST isos HELLO=WORLD
The interface¶
the openqa_cli can take two additional parameters. One will enable scripts to run before the data format and the second after.
The scripts can be separated per folders, which will contain both sorts of scripts, and which they will be distiguished by a prefix.
examples:
/hook/<awesome_scripts_set>/
- pre_<script_name>
- post_<another_or_the_same_name>
So the interface will define:
--pre-script-hook <path_to/awesome_scripts_set>
--post-script-hook <path_to/awesome_scripts_set>
I moved on with the code which is tested for a hello_world script. Despite this ticket is not for the full implementation I think, what we have so far It is enough to move one with the idea. I still have to push the changes but I got a bit obsessed with some ideas.
AC status¶
AC1: We know what we need to change in our current mechanism for triggering tests in the light of #159828.
I think it is more clear now.
We agree with Santi to move on with the changes on openqa_cli and then continue with the integration of the result on openqa-trigger-from-obs.
AC2: We know who (which team) is going to change what parts.
So we have three main tasks:
openqa_cli
is on qatoolsopenqa-trigger-from-obs
is likely possible to be done by qatoolsscripts
by core-team. But I think that there need a template which is something which both teams can collaborate and provide.
Actually this last is what I am experiment with atm.
I will push/update PR asap
Updated by ybonatakis 3 months ago
- Status changed from In Progress to Feedback
on feedback based on last comment
Updated by okurz 3 months ago
ybonatakis wrote in #note-11:
Today at the programming session with @szarate we defined the interface and tested the idea.
The idea¶
Original call:¶
openqa-cli api --post-script-hook hook/awesome_scripts_set --host http://127.0.0.1:9526 -X POST isos BETA=1
Script post_foobar is called| it removed BETA=1¶
openqa-cli api --post-script-hook hook/awesome_scripts_set --host http://127.0.0.1:9526 -X POST isos FOO=BAR
Script post_hello_world is called | it added HELLO=WORLD¶
openqa-cli api --post-script-hook hook/awesome_scripts_set --host http://127.0.0.1:9526 -X POST isos FOO=BAR HELLO=WORLD
Invoke all together. Should be also possible¶
openqa-cli api --post-script-hook hook/awesome_scripts_set -f -D data.json --host http://127.0.0.1:9526 -X POST isos HELLO=WORLD
The interface¶
the openqa_cli can take two additional parameters. One will enable scripts to run before the data format and the second after.
The scripts can be separated per folders, which will contain both sorts of scripts, and which they will be distiguished by a prefix.
What do you mean "run before the data format"?
examples:
/hook/<awesome_scripts_set>/ - pre_<script_name> - post_<another_or_the_same_name>
So the interface will define:
--pre-script-hook <path_to/awesome_scripts_set>
--post-script-hook <path_to/awesome_scripts_set>
I moved on with the code which is tested for a hello_world script. Despite this ticket is not for the full implementation I think, what we have so far It is enough to move one with the idea. I still have to push the changes but I got a bit obsessed with some ideas.
And what do the hook scripts offer what can not be done by test variables passed in the same invocation?
AC status¶
AC1: We know what we need to change in our current mechanism for triggering tests in the light of #159828.
I think it is more clear now.
We agree with Santi to move on with the changes on openqa_cli and then continue with the integration of the result on openqa-trigger-from-obs.
The relevant question I have here is how the hook scripts would be discovered from openqa-trigger-from-obs?
AC2: We know who (which team) is going to change what parts.
So we have three main tasks:
openqa_cli
is on qatoolsopenqa-trigger-from-obs
is likely possible to be done by qatools
What is "qatools"? I guess you mean "SUSE QE Tools"? Assuming that following on I wonder what do you mean with "openqa-trigger-from-obs
is […] to be done by [SUSE QE Tools]"?
scripts
by core-team. But I think that there need a template which is something which both teams can collaborate and provide.
With scripts
do you mean "openqa-cli hook scripts"? If yes then the idea would be that they live in "openqa-trigger-from-obs"
Updated by livdywan 3 months ago · Edited
- By
openqa-cli
which could take another parameter--hook-script
and would call this script with all test variables specified on the command-line. The script can then amend this list of test variables beforeopenqa-cli
makes the actual API request.
Discussed this briefly on Jitsi. So apparently https://github.com/os-autoinst/openQA/pull/5757 implements this proposal.
An open question is how that would be used in production. So please provide a pull request showing how to use this.
Updated by ybonatakis 3 months ago
- Status changed from Feedback to Resolved
I tried to provide the integration but I wanted to work first on openqa-cli.
My problem was trying to pass the @data into the hook script with open my $fh, '-|', "./$hook_path @args";
This was failing with
sh: -c: line 1: syntax error near unexpected token `('
sh: -c: line 1: `./hook/superscript/post_testme HASH(0x562552eab240)'```
As the time limit of 20h was over, I will close this.
The next step as discussed is to let Oli take over and discuss the findings with Santi to come up with the final requirements, according the discussion and the work from Marius and the latest PR from this ticket https://github.com/os-autoinst/openQA/pull/5757
Updated by okurz 3 months ago
- Copied to action #164388: [timeboxed:20h][spike solution] Adaptable product scheduling in openqa-trigger-from-obs - take 2 added
Updated by okurz 9 days ago
- Related to action #164454: Dynamic schedule with logic executed by "products post" before job templates are evaluated added