Re: [Xen-devel] [OSSTEST PATCH RFC 06/14] Introduce ts-xtf-build [and 1 more messages]

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Wei Liu writes ("Re: [OSSTEST PATCH RFC 06/14] Introduce ts-xtf-build [and 1 
more messages]"):
> On Thu, Aug 04, 2016 at 04:17:45PM +0100, Ian Jackson wrote:
> > The ability to coinstall multiple different xtfs was my reason for
> > suggesting that the xtfdist should be unpacked into a job-specific
> > subdirectory of /home/osstest.  Obviously that would have to be a
> > directory specific to the _test job_, not the build job.
...
> Note that xtf won't generate any artefacts during runtime.

Yes.

> The test jobs are tied to a specific build job in one flight, so I think
> a build job specific path (as coded) would be the same as test job
> specific path.

That is how the flights are constructed right now, yes.

But it is not in general a good idea to bake too many of these
assumptions into the ts-* scripts.  It's not easy to imagine today why
a single test host might want to be subjected to multiple xtf runs,
but it seems hard to rule out.

For example, in the future, host sharing may mean that different test
jobs for the same flight are run on the same host.  Of course these
wouldn't be your existing multiple xtf jobs (for several reasons).

But if there were ever some xtf test jobs which were different in some
way, then in principle it would be possible for each xtf test job to
specify a differnet xtf build job.  This would mean installing xtf
more than once, from what may be different build jobs or what may be
the same build job.

Whether they are the same build job might not depend on things
specified directly in make-flight and mfi-*.  Automatic job
constructors can reuse jobs from other flights and/or construct new
flights using old ones as templates.  The bisector will choose build
jobs as it sees fit.

If an xtfdist would work if unpacked in a different directory, which
wasn't known at build time, it would be possible for each xtf test job
to unpack its xtfdist in the directory corresponding to the test job.

Thus multiple test jobs with potentially-different xtfs could run
sequentially on the same host.

However, that is not possible.  (Unpacking the same xtf over the top
of itself might not be safe and wouldn't be a good idea.)

Therefore, we will have to remember this limitation if we ever are
likely to come across it.  Fine.

But that does mean that my suggestion for using a job-specific
location for the xtf installed version is pointless.  The
(impossible) scheme depends on a _test_-job-specific location.  There
is no point embedding the _build_ job info in the pathnames.

And as you discover, doing so means that the pathname needs to be made
available in a runvar.  This is pointless complexity.

> If you have different test jobs that depend the same build job, using
> the same build should be fine. If you have test jobs that depend on
> different build job, obviously the path would be different, too.

This seems to contemplate unpacking the same xtf over the top of
itself.  I don't think this is a good idea.  For example, if we ever
do parallel runs, it would break.  It might also overwrite useful logs
etc.

Ian.

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