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

["Hu, Robert" <robert.hu@xxxxxxxxx>]

Thanks Ian.
So strange, seems this mail was sent ' Tuesday, September 1, 2015 10:42 PM ', 
but I 
have just received it.
I'm fully occupied by some release test, so have to carefully read your 
comments 1 ~2
weeks later. Sorry about this.

Best Regards,
Robert Ho

> -----Original Message-----
> From: Ian Campbell [mailto:ian.campbell@xxxxxxxxxx]
> Sent: Tuesday, September 1, 2015 9:52 PM
> To: Hu, Robert; Ian Jackson
> Cc: xen-devel@xxxxxxxxxxxxx; wei.liu2@xxxxxxxxxx
> Subject: Re: [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of
> nested test job
> 
> On Tue, 2015-08-18 at 06:46 +0000, Hu, Robert wrote:
> 
> Sorry for the delay, I've been away.
> 
> > > -----Original Message-----
> > > From: Ian Jackson [mailto:Ian.Jackson@xxxxxxxxxxxxx]
> > > Sent: Thursday, June 25, 2015 6:22 PM
> > > To: Pang, LongtaoX
> > > Cc: Ian Campbell; Hu, Robert; xen-devel@xxxxxxxxxxxxx;
> > > wei.liu2@xxxxxxxxxx
> > > 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"):
> > > > > -----Original Message-----
> > > > > From: Ian Campbell [mailto:ian.campbell@xxxxxxxxxx]
> > > ...
> > > > > I think you are correct, the logs capture will fail too.
> > > > >
> > > > > I'll leave it to Ian to suggest a solution since it will no doubt
> > > > > involve some tcl plumbing (I'd be inclined to record 'hosts which
> > > > > are
> > > > > actually guests' somewhere and have the infra clean them up
> > > > > automatically after doing leak check and log collection).
> > >
> > > Sorry I haven't done this yet, it's still on my radar.
> > >
> > > > > I was thinking more along the lines of creating
> > > > > Osstest/PDU/guest.pm
> > > > > with the appropriate methods calling out to toolstack($l0)->foo,
> > > > > setting
> > > > > $ho->{Power} = 'guest $l1guestname' somewhere and allowing
> > > > > power_cycle_host_setup to do it's thing.
> > > >
> > > > I have reviewed power_cycle_host_setup function, inside this
> > > > function will call get_host_method_object, then we could get a $mo
> > > > which will be assigned to $ho->{PowerMethobjs}, right?  Inside
> > > > power_state function, it will call pdu_power_state which is defined
> > > > in guest.pm, right?
> > >
> > > Yes.
> > I'm not quite sure about how @$methobjs is obtained.
> > sub power_cycle_host_setup ($) {
> >     my ($ho) = @_;
> >     my $methobjs = [ ];
> >     foreach my $meth (split /\;\s*/, $ho->{Power}) {
> >     push @$methobjs, get_host_method_object($ho,'PDU',$meth);
> >     }
> >     $ho->{PowerMethobjs} = $methobjs;
> > }
> > Seems it is derived from $ho->{Power} while $ho->{Power} is defined by
> > either:
> > 1. selecthost()
> >     $ho->{Power}= get_host_property($ho,'power-method');
> > 2. default_methods()
> >     $ho->{Power} ||= "statedb $ho->{Asset}";
> >   Seems no statedb for standalone mode.
> 
> Indeed, statedb is actually peculiar to the old Cambridge instance of
> osstest, it's not used in the production colo. In fact it is also not used
> in Cambridge any more, every host has a power-method host property. In
> standalone mode the default {Power} is "manual" I think, that's the one
> which prompts you to press a key.
> 
> The {Power} property is essentially a ";" separated list, each list entry
> is "<module> <arg1> <arg2> <...>". <module> is Osstest/PDU/<module>.pm
> and
> <arg1> <arg2> <...> are passed to the constructor. These objects are
> constructed by get_host_method_object.
> 
> Then on power operation the appropriate method each object is called in
> turn (so you can call multiple modules if needed by the host).
> 
> > So how shall I assign $ho->{Power} method? by statically through config
> > file?
> > or some generic way automatically identify $host is some guest, therefore
> > assign 'guest' to $ho->{Power}?
> > Would you give me some idea? thanks.
> 
> I'm not sure. Something in selecthost would need to know somehow that the
> host being requested was actually an L1 guest.
> 
> Ian, any ideas?
> 
> Ian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel