On Tue, 2017-04-18 at 06:35 -0600, Tim Flink wrote:
One of the things that seems like it is and will be a pain point for
folks writing package-specific tasks is how to work through the times
when there was an issue in the task and things didn't run well. At the
moment, the only solution we have is to re-build the affected package
or to pester an admin to re-run the trigger - neither of which is an
I was thinking about how to improve this in the near future and am
wondering about adding a "reschedule" button to execdb jobs:
1. authenticated user clicks on "reschedule" button
2. execdb makes an api call to the buildmaster to find the parameters
which were used for that task
3. using the data from 2), execdb starts a new job for just that
item and item type
I'm not thrilled at the idea of code duplication here between trigger
and execdb but compared to figuring out a web interface for trigger,
this seems like a more tractable solution for the short/medium term.
Here's a Half-Baked Idea (tm):
What about a thing that's basically a simple web service that allows
FAS-authenticated people to trigger the sending of templated fedmsgs?
This could be used in various workflows like this. For this case, we'd
implement a fedmsg template which would basically say 'authenticated
user X asks that you please re-run test Y in test system Z'. Then we
could plug little bits of code into Bodhi, execdb, really anything else
you like, which would provide a button which, when clicked, calls out
to that web service to send the 'restart test' fedmsg.
The test dispatchers for Taskotron, openQA etc. would then just need to
listen out for such fedmsgs, and do whatever they felt appropriate: you
could implement policy at the dispatcher level - ignore requests from
users without certain attributes (or even stash them for manual review,
or something), accept requests from other users with different
priorities, stuff like that. For feedback...well, if the test *did* get
restarted, a fedmsg will naturally be emitted which the requesting
system could listen out for, and if the scheduler decided to reject or
sideline the request, it could emit a fedmsg saying it had done so.
OK, like I said, half-baked =) But wdyt?
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net