On Fri, 21 Oct 2016 13:16:04 +0200
Josef Skladanka <jskladan(a)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