[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |