Re: [Xen-devel] [PATCH v6 19/20] osstest: save/retrieve the last successfully tested FreeBSD build

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Roger Pau Monne writes ("Re: [PATCH v6 19/20] osstest: save/retrieve the last 
successfully tested FreeBSD build"):
> On Mon, Jul 24, 2017 at 04:56:25PM +0100, Ian Jackson wrote:
> > Also I would like you to discuss explicitly (in a comment or commit
> > message) about whether push or anoint should come first.  If push
> > comes first then we can end up pushed but not anointed; and, vice
> > versa.  What are the recovery arrangements from such a failure ?
> 
> Hm, that's a hard one. I think push should be our primary goal, and as
> such we should try to do the push first, so that a failed anoint
> doesn't prevent a push.
> 
> OTOH, doing a push and failing on anoint doesn't seem that critical,
> osstest can still use the oldish anointed artifacts and continue
> working, hoping that on the next pass the anoint will succeed.

But there might not be a next pass.  When we push, we overwrite the
state information that triggered the run.  So we push first, and the
anoint fails, then we end up in a state where if the input branch
doesn't change, osstest won't run a new flight.

Conversely, if we anoint first: if a flight is anointed, but the
corresponding revision is not pushed, then osstest ought to rerun the
flight and do a further anoint (and hopefully a push).  But this does
mean that osstest might anoint a series of identical outputs,
defeating the point of keeping a few older versions.

A third option would be to push first, but to call mg-anoint and/or
sg-check-tested to figure out whether the pushed revision was anointed
and run the flight unconditionally if not.  An advantage of this is
that if osstest is modified to add an architecture, this check would
automatically fail and a flight would be run to generate the first
"proper" anointed build from the (presumably preseeded by hand) ad-hoc
anointed build.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel