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 Jackson [mailto:Ian.Jackson@xxxxxxxxxxxxx]
> Sent: Tuesday, September 1, 2015 10:42 PM
> To: Ian Campbell
> Cc: Hu, Robert; xen-devel@xxxxxxxxxxxxx; wei.liu2@xxxxxxxxxx
> Subject: Re: [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of
> nested test job
> 
> Hi Robert.  Sorry I haven't had a chance to look at your whole v11
> series properly yet.  But I will reply here:
> 
> Ian Campbell writes ("Re: [OSSTEST Nested PATCH v11 6/7] Compose the
> main recipe of nested test job"):
> > Then on power operation the appropriate method each object is called in
> > turn (so you can call multiple modules if needed by the host).
> 
> Ian's explanation is right.
> 
> > > 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.
> 
> I think this would be correct.
> 
> > Ian, any ideas?
> 
> I was expecting there to be a runvar which would for an L1 guest give
> the ident of its host.  ts-nested-setup would set this runvar and
> selecthost would look at it.
> 
> There are various possible exact syntaxes but I think the best one is
> probably that the runvar which ordinarily gives the name of a real
> host instead contains the containing host name and the L1 guest name.
> 
> So if you do
>   ./ts-nested-setup l0_host l1
> then you get a runvar `l1' with value `l0_host:l1'.
> 
> selecthost would see the colon, and set $ho->{Host} to `l0_host', so
> that get_target_property's recursion into containing hosts works
> properly.
> 
> selecthost would also be able to see that $ho->{Host} being set meant
> it was a nested guest, and that therefore power operations should be
> done by running toolstack operations on the host.  (Rather than
> looking up a host property.)
> 
> It also needs to arrange that for an L1 (well, anything with
> $ho->{Host} aka the _nestedhost runvar), the MAC address is read (into
> $ho) from the runvar which is created by the guest creation, rather
> than being looked up as a host property.  Then the functions for
> finding the IP address by asking the DHCP server have the right input.
> 
> The $ho->{DiskDevice} setting in selecthost is wrong too.
> 
> This is all probably most easily achieved by having the part of
> selecthost which deals with L1 guests seed $ho->{Properties} with
> appropriate information.
> 
> You want to make "----- calculation of the host's properties -----"
> conditional, and do something entirely different (ie, populate
> $ho->{Properties} and perhaps some of $ho->{Flags}) when $ho->{Host}
> is set.
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel