Re: [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of nested test job

[Ian Campbell <ian.campbell@citrix.com>]

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@eu.citrix.com]
> > ...
> > > > 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.