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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 04/08/16 17:05, Ian Jackson wrote:
> 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.

The current hard-coded paths exist only because of current limitiations
in xl/libxl (identified here:
http://xenbits.xen.org/people/andrewcoop/xen-test-framework/#errata)

With those issues fixed, XTF can be made to be entirely filesystem
location independent.

~Andrew

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