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

["Pang, LongtaoX" <longtaox.pang@xxxxxxxxx>]

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@xxxxxxxxxxxxx]
> Sent: Friday, June 12, 2015 11:27 PM
> To: Pang, LongtaoX
> Cc: xen-devel@xxxxxxxxxxxxx; Ian.Campbell@xxxxxxxxxx; wei.liu2@xxxxxxxxxx; Hu,
> Robert
> Subject: RE: [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.
> 
I have tried your suggestion, call 'add-xen-host- retrospectively l1' just 
after L1 has booted into XEN.
leak-check and logs-capture will be done automatically at final stage, but this 
happened after L1 guest destroyed 
and it will failed obviously(I have mentioned this in previous mail). 
So, may I implement these action via below recipe in sg-run-job? Since, this 
would be less code to 
be changed and we want to avoid to involve tcl plumbing in sg-run-job. Also, I 
think there is no harmful.
proc need-hosts/test-nested {} {return host}
proc run-job/test-nested {} {
    run-ts . = ts-debian-hvm-install + host l1
    run-ts . = ts-nested-setup + host l1
    run-ts . = ts-xen-install l1
    run-ts . = ts-host-reboot l1
    run-ts . = ts-leak-check basis l1
    run-ts . = ts-debian-hvm-install l1 l2
    run-ts . = ts-guest-stop l1 l2
    run-ts . = ts-leak-check check l1
    run-ts . = ts-logs-capture l1
    run-ts . = ts-guest-destroy + host l1
}
> 
> 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