From mboxrd@z Thu Jan  1 00:00:00 1970
From: Robert Hu <robert.hu@vmm.sh.intel.com>
Subject: Re: [OSSTEST Nested PATCH v11 6/7] Compose the main
 recipe of nested test job
Date: Sun, 14 Jun 2015 20:51:25 +0800
Message-ID: <1434286285.25577.6.camel@localhost>
References: <1432631304-27347-1-git-send-email-longtaox.pang@intel.com>
	<1432631304-27347-7-git-send-email-longtaox.pang@intel.com>
	<21880.23264.813171.606123@mariner.uk.xensource.com>
	<86C3224E41A7434B904EC364302132D80E4BFEC4@SHSMSX101.ccr.corp.intel.com>
	<21881.42757.84361.654532@mariner.uk.xensource.com>
	<86C3224E41A7434B904EC364302132D80E4C0A6B@SHSMSX101.ccr.corp.intel.com>
	<21882.64076.306554.733060@mariner.uk.xensource.com>
Reply-To: robert.hu@intel.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <21882.64076.306554.733060@mariner.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "Hu, Robert" <robert.hu@intel.com>, "Pang,
	LongtaoX" <longtaox.pang@intel.com>, "wei.liu2@citrix.com" <wei.liu2@citrix.com>, "Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

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.
> 
> 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?
> 
> Ian.