[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.