From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Jackson Subject: Re: [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of nested test job Date: Tue, 1 Sep 2015 15:41:31 +0100 Message-ID: <21989.47387.157970.104150@mariner.uk.xensource.com> 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> <1434286285.25577.6.camel@localhost> <1434359303.13744.16.camel@citrix.com> <86C3224E41A7434B904EC364302132D80E4C30D5@SHSMSX101.ccr.corp.intel.com> <1434533714.13744.279.camel@citrix.com> <86C3224E41A7434B904EC364302132D80E4C70CF@SHSMSX101.ccr.corp.intel.com> <21899.54829.184298.240762@mariner.uk.xensource.com> <9E79D1C9A97CFD4097BCE431828FDD31DBF029@SHSMSX103.ccr.corp.intel.com> <1441115502.26292.33.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1441115502.26292.33.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "Hu, Robert" , "wei.liu2@citrix.com" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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.