[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of nested test job
Pang, LongtaoX writes ("RE: [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of nested test job"): > > From: Ian Jackson [mailto:Ian.Jackson@xxxxxxxxxxxxx] ... > > leak-check compares the set of objects present at the `leak-check > > check' step with the set of objects present at the `basis' step, and > > the check fails if there are any new objects. For this purpose, > > objects includes domains, corefiles, etc. > > > OK, so the recipe in sg-run-job should be like below, please correct me if > something wrong. > proc need-hosts/test-nested {} {return host} > proc run-job/test-nested {} { This is roughly right, but thinking about it, you want ts-logs-capture to run even if the previous steps fail. I think it might be better to reuse (subvert?) the existing machinery in sg-run-job, by adding the l1 to need_xen_hosts. Maybe something like proc add-xen-host-retrospectively {ident} { global need_xen_hosts ts-leak-check $ident + basis lappend need_xen_hosts $ident } ? And then call add-xen-host-retrospectively l1 at the appropriate point. If you do this then the main run-job proc will automatically do the leak-check and the logs-capture for you. Thinking about this leads me to ask another question. Suppose that a bug causes the l1 to lock up completely. ts-logs-capture will attempt to hard reboot a locked-up host. If it can't fetch any logs, it calls target_reboot_hard($ho); What will that do if $ho refers to the l1 ? It relies on the power method. Does your nested l1 "host" have a power method ? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |