On 05/03/2016 03:31 AM, Róman Joost wrote:
I'd like to share a new design proposal which hopefully addresses some
of the issues people have when larger jobs fail because of broken
Kudos to Bruno Goncalves who brought it initially to my attention.
Is there something the proposal misses? Are there perhaps details which
are not correctly flashed out? Do you have questions?
I'm glad Beaker is getting rescheduling capabilities!
Will the abort and reschedule be atomic? I.e. will it be impossible for
beaker-jobwatch to see the aborted recipe before it's cloned?
How to identify re-scheduled recipe sets¶
A UI element will be used to make them distinguishable from regular scheduled recipe
Please make it easily discoverable from the result xml as well. e.g. the
aborted recipe could have an attribute rescheduled_as="RS:XYZ"?
c) would it be possible to (optionally?) NAK the aborted recipe?
d) Slightly related: with beaker-jobwatch I struggle to make people
investigate the cause of the aborts = if reschedule works they get their
results and no longer care that some other recipeset failed to finish. I
expect Beaker to have the same issue once it starts "fixing" jobs. Do
you have any ideas how to persuade people to investigate these?
/me currently plans to add a phone-home feature to beaker-jobwatch that
would log all failed-to-finish recipesets into
logstash/ElasticSearch/Kibana, hoping that it will help me spot patterns
of failures and report better tickets.
Beaker-devel mailing list
DevOps in BaseOS QE,