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

Re: [Xen-devel] [PATCH v4 11/16] osstest: introduce a script to set the runtime hostflags runvar for FreeBSD jobs



Roger Pau Monne writes ("[PATCH v4 11/16] osstest: introduce a script to set 
the runtime hostflags runvar for FreeBSD jobs"):
> Due to the nature of the FreeBSD install media, which is
> self-generated from the ts-freebsd-build script, the hostflags runvar
> set to FreeBSD jobs are related to the current version under test.
...
> +set_runtime_hostflag("host",
> +                     "share-build-freebsd-$arch-$hash,freebsd-$version");

So, having thought about this:

You are currently unconditionally calling this script for build jobs,
allowing it to assume the host ident name.

You don't call it at all for test jobs.  This is wrong because test
jobs need the freebsd-* hostflag too.

Currently there is no test job sharing, so they need not to have the
share-* flag.

I think this means this ts-freebsd-set-hostflags script needs to be
told somehow what flags to set.  Since the sharetype is calculated
from the share-* hostflag by ts-hosts-allocate-Executive, but then
recalculated from the parameters to
$mjobdb->jobdb_resource_shared_mark_ready, the code and runvars need
to be coordinated so there is no problem making the hostflag be
approximately-fixed.

So I suggest adding a --share flag to ts-freebsd-set-hostflags.


Also: you have not noticed this because currently nothing call
$mjobdb->jobdb_resource_shared_mark_ready.  Normally this is done by
ts-xen-build-prep which is run by prepare-build-host-linux.  You
haven't noticed that you aren't calling this because currently you
aren't building Xen at all.

One way to deal with this would be to fix ts-xen-build-prep for
FreeBSD (at least to the point where it runs to completion, even if
not all the Xen build-dependencies are installed), and then call it in
prepare-build-host-freebsd.  But that looks quite annoying because
ts-xen-build-prep reorganises the storage in rather linux-specific
ways.

Another would be to split out the call to
  $mjobdb->jobdb_resource_shared_mark_ready
from ts-xen-build-prep into its own script ts-host-shared-ready.
That new script would have to gain a substitution system.

An ad-hoc method would be to call
  $mjobdb->jobdb_resource_shared_mark_ready
from ts-freebsd-install.  That seems to suggest FreeBSD installs not
needing different storage arrangements or something for build hosts
and test dom0s.

If you were feeling keen, you could sort out the anomaly that is a
test script calling straight into $mjobdb.  Eg.
  1. Rename resource_shared_mark_ready to
      executive_resource_shared_mark_ready and change all callers.
  2. Introduce a wrapper resource_shared_mark_ready
      which calls $mjobdb->jobdb_resource_shared_mark_ready
     and change the call in ts-xen-build-prep to use it.


I'll come to you in a moment to handwave at you about all this.

Ian.

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

 


Rackspace

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