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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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