[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH OSSTEST v2] cs-adjust-flight: Add jobs-rename command which applies a perlop to job names

On Tue, 2016-01-19 at 14:25 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST v2] cs-adjust-flight: Add jobs-
> rename command which applies a perlop to job names"):
> > My intention was to allow creation of adhoc jobs based on a template
> > but modified e.g. to enable/disable XSM with a sequence something
> > like:
> ...
> > Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> > Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> I know I acked this, and my next observations don't mean we shouldn't
> apply it as-is, but:
> > +ÂÂÂÂUPDATE jobs
> > +ÂÂÂÂÂÂÂSET job = ?
> > +ÂÂÂÂÂWHERE flight = ? AND job = ?
> > +END
> This can be applied to flights in intended blessing `play' in
> blessings later than `constructing', or via `running:F' to running
> flights.
> And if that happens, there might be entries in the steps table which
> ought also to be renamed.ÂÂIf you don't rename them you will trip the
> foreign key constraint.

But fail immediately in this invocation of cs-adjust-flight with a
(hopefully) comprehensible SQL error spew?

Or is that the distinction between INNTIALLY IMMEDIATE vs DEFERRED you were
trying to get at?

Having stuffed the flight in this way would it have effects elsewhere (i.e.
on production flights) or do you just get to keep both pieces of this
particular flight?

> I think a similar problem exists with jobs_del.
> Note that this constraint is INITIALLY IMMEDIATE.ÂÂIf we were to make
> it INITIALLY DEFERRED then this code would become dangerous, because
> ÂÂÂ./cs-adjust-flight F jobs-rename x 's/x/y/' copy-jobs G x
> would leave F.x containing the steps from the old x but the
> recipe and runvars from G.x.ÂÂBut I don't think INITIALLY DEFERRED is
> a good default for constraints so this is probably not relevant.
> Ian.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.