There's not been a huge amount of effort put to this - I've had other priorities ever since, but I can get back on it, if you feel it's the time to do it. The only code to work in that direction is here: https://bitbucket.org/fedoraqa/execdb/branch/feature/pony where I only basically started on removing the tight coupling between execdb and buildbot, and then I went on trying to figure out what's in this thread.
On Tue, Jan 10, 2017 at 6:57 AM, Tim Flink <tfl...@redhat.com> wrote: > On Fri, 21 Oct 2016 13:16:04 +0200 > Josef Skladanka <jskla...@redhat.com> wrote: > > > So, after a long discussion, we arrived to this solution. > > > > We will clearly split up the "who to notify" part, and "should we > > re-schedule" part of the proposal. The party to notify will be stored > > in the `notify` field, with `taskotron, task, unknown` options. > > Initially any crashes in `shell` or `python` directive, during > > formula parsing, and when installing the packages specified in the > > formula's environment will be sent to task maintainers, every other > > crash to taskotron maintainer. That covers what I initially wanted > > from the multiple crashed states. > > > > On top of that, we feel that having an information on "what went > > wrong" is important, and we'd like to have as much detail as > > possible, but on the other hand we don't want the re-scheduling logic > > to be too complicated. We agreed on using a `cause` field, with > > `minion, task, network, libtaskotron, unknown` options, and storing > > any other details in a key-value store. We will likely just > > re-schedule any crashed task anyway, at the beginning, but this > > allows us to hoard some data, and make more informed decision later > > on. On top of that, the `fatal` flag can be set, to say that it is > > not necessary to reschedule, as the crash is unlikely to be fixed by > > that. > > > > This allows us to keep the re-scheduling logic rather simple, and most > > imporantly decoupled from the parts that just report what went wrong. > > How far did you end up getting on this? > > Tim > > _______________________________________________ > qa-devel mailing list -- qa-devel@lists.fedoraproject.org > To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org > >
_______________________________________________ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
