[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 variable. 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 runtime_IDENT_hostflags runtime_all_hostflags mirroring the existing IDENT_hostflags all_hostflags > > > +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? No. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |