action #162515
opencoordination #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 22 days 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 21 days 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 15 days 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 9 days ago
- Status changed from Workable to In Progress
- Assignee set to ybonatakis
Updated by openqa_review 9 days ago
- Due date set to 2024-07-23
Setting due date based on mean cycle time of SUSE QE Tools
Updated by ybonatakis 7 days 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 6 days ago
Updated by ybonatakis 5 days 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 days ago
- Status changed from In Progress to Feedback
on feedback based on last comment
Updated by okurz 2 days 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"