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
pgpZnfeI5dQEn.pgp
Description: OpenPGP digital signature
_______________________________________________ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
