On Tue, 18 Apr 2017 14:53:07 +0200
Kamil Paral <kparal(a)redhat.com> wrote:
On Tue, Apr 18, 2017 at 2:35 PM, Tim Flink <tflink(a)redhat.com>
> 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 ideal answer.
> I was thinking about how to improve this in the near future and am
> wondering about adding a "reschedule" button to execdb jobs:
Execdb web is not searchable, people will never find their job. It
makes a lot of sense to have the button in execdb, because that's
where we want to show people crashed jobs (those will not appear
neither in resultsdb nor in Bodhi). So thumbs up to that idea. But
the search seems to be a prerequisite to this. Or we need to make
sure crashed jobs are sent out with direct links to execdb to the
relevant maintainers, if that turns out to be easier.
Yeah, it's not an ideal solution but in my mind, it's better than
asking folks to rebuild just to get the task re-run.
> 1. authenticated user clicks on "reschedule" button
Authentication itself sounds like a non-trivial issue. I wonder if we
can avoid it at least temporarily. Maybe allow anyone to click the
button, but limit the number of times it can be pressed (e.g. max 5
times)? Also introduce a timeout after the press (max once per hour
since the last re-run), and don't allow to re-run old jobs (e.g.
older than 24 hours)?
Maybe authentication will be easier after all :) Maybe we don't even
need to check package permissions in the beginning, just making sure
the person has a valid FAS (cla+1) account.
I was hoping that we'd be able to auth against ipsilon without much
added effort. Ideally we'd restrict things to someone with ACLs to the
involved package but that's far from required.
cla+1 should be good enough for now, I think. Limiting it to
packagers could also be reasonable but I'm not sure it's going to be a
big deal so long as we can keep track of who's doing the reschedules
through at least a log file.
> 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.
> qa-devel mailing list -- qa-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to