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

Re: [Xen-devel] [PATCH v3 6/8] osstest: introduce a script to set the hostflags for FreeBSD jobs

Roger Pau Monne writes ("Re: [PATCH v3 6/8] osstest: introduce a script to set 
the hostflags for FreeBSD jobs"):
> On Fri, Jun 23, 2017 at 04:10:47PM +0100, Ian Jackson wrote:
> > In fact, I don't know how this script can have worked for you.
> > Currently many build jobs have the runvar "host_hostflags" including
> > many flags including "arch-i386" say, which I assume your FreeBSD
> > build jobs will have from make-flight too.  (It is forbidden, and
> > prevented, for a ts-* script to use store_runvar to modify a runvar
> > provided as part of the job definition.)
> In this case host_hostflags is not part of the job definition.

That is precisely what I am complaining about.

The very same runvar cannot be set both at job creation and later by a
ts-* script.

I know you are not doing this with the very same runvar (because you
are setting host_hostflags at runtime and all_hostflags at job
creation time), but IMO similar runvars should not normally be set at
job creation in some cases and by ts-* scripts in others.  This is
certainly true of "portmanteau" runvars like the hostflags ones, whose
contents need to be assembled out of various pieces.

If you do things the way you do right now, we would be unable to use
the host_hostflags runvar for its current purpose, if we decided we
wanted to in the future, because you'd used it as a runtime-set

Currently, FOO_hostflags variables are all set during test definition
and I would like that to remain true.

You legitimately need to set some hostflags, to affect host
allocation, in a ts-* script.  So your new runtime-defined runvars
should have new names.  This is why I suggested this:

> > I think you should probably invent something like
> >   runtime_IDENT_hostflags
> > and teach ts-hosts-allocate-Executive about it.
> What should I store in this runvar?

The same thing as you are currently storing in host_hostflags.  A
comma-separated list of the flags.

> arch is not a problem because it's available at job creation, but both
> <version> and <hash> are more difficult to get, because they might
> come from a previous flight, and get_runvar must be executed from a
> job context, or else it fails. That's the reason I needed to set
> host_hostflags from a ts script, so that I could use get_runvar.

I'm saying you should introduce a new runvar, which is exactly like
host_hostflags except that we expect to define it with a ts-* script
rather than in the job definition.

In fact, a new _family_ of runvars
mirroring the existing

> > > +store_runvar("host_hostflags", $r{"extra_hostflags"} .
> > > +             ",share-build-freebsd-$arch-$hash,freebsd-$version");
> > 
> > "extra_hostflags" would be the host flags for the host ident extra.
> Just so that this is clear to me. When creating the job the
> host_hostflags variable should not be set (when calling
> job_create_build), and ts-hosts-allocate-Executive should set the
> host_hostflags itself?



Xen-devel mailing list



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