[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
On Sun, 2015-06-14 at 20:51 +0800, Robert Hu wrote: > On Fri, 2015-06-12 at 16:27 +0100, Ian Jackson wrote: > > 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. > Thanks Ian J.. Since I'm not familiar with tcl and your sg-run-job > framework, does here 'appropriate point' refers to before > per-host-ts . =(*) {ts-leak-check basis} > in proc run-job {job}? but then l1 doesn't exist yet I'm afraid. > If after that point, the l1 has missd check basis step. Note that Ian included a ts-leak-check in his add-xen-host-retrospectively function, so you needn't worry about this, you should do it jsut after the L1 has booted into Xen, I think. What you get automatically here is the final leak check (i.e. the comparison against the basis). > > 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 ? > I'm afraid l1 won't like normal hosts has power cycle operations. Maybe > we need to simulate it? Perhaps arrange for an appropriate PowerMethod for "hosts which are actually guests"? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |