Open Stack

I thought it could be used for anything on the XenAPI side too, although I have not tried it that way yet.

We have posted some docs on the XenAPI side.
Around the pooled live migration that uses this anyway:
https://review.openstack.org/#/c/13202/

Cheers,
John

From: openstack-bounces+john.garbutt=citrix.com at lists.launchpad.net [mailto:openstack-bounces+john.garbutt=citrix.com at lists.launchpad.net] On Behalf Of Joe Gordon
Sent: Wednesday, September 19, 2012 11:45 PM
To: Day, Phil
Cc: openstack at lists.launchpad.net (openstack at lists.launchpad.net) (openstack at lists.launchpad.net)
Subject: Re: [Openstack] Generalsied host aggregates in Folsom


On Wed, Sep 19, 2012 at 1:14 PM, Day, Phil <philip.day at hp.com<mailto:philip.day at hp.com>> wrote:
Thanks Joe,

I was anticipating something more complex to be able to say when an aggregate should or shouldn't be linked to the hypevisor and overlooked the obvious.

So just to make sure I've  got it - on libvirt systems an aggregate can be used for anything (because of the NoOp in the driver), but on xen systems it's still liked to the hypervisor pools ?

Libvirt can be used for anything.

And Xen can be a xen hypervisor pool or anything depending on the aggregate metadata (https://github.com/openstack/nova/blob/master/nova/virt/xenapi/pool.py#L80
https://github.com/openstack/nova/blob/master/nova/virt/xenapi/pool_states.py)

Thanks
Phil

From: Joe Gordon [mailto:jogo at cloudscaling.com<mailto:jogo at cloudscaling.com>]
Sent: 19 September 2012 19:02
To: Day, Phil
Cc: openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net> (openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>) (openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>)
Subject: Re: [Openstack] Generalsied host aggregates in Folsom


On Wed, Sep 19, 2012 at 10:18 AM, Day, Phil <philip.day at hp.com<mailto:philip.day at hp.com>> wrote:
Hi Folks,

Trying to catch-up  (I'm thinking of changing my middle name to catch-up :)  ) with the generalisation of host aggregates - and looking at the code it looks to me as if the chain for adding a host to an aggregate still ends up calling the virt layer

api/openstack/compute/contrib/aggregates/AggregateController/action()
compute/api/AggregateAPI/add_host_to_aggregate()
<RPC>
compute/manager/add_aggregate_host()
virt/add_to_aggregate()

I thought the change was to be able to create aggregates that can be linked to a hypervisor concept, but could also just be a way of "tagging" hosts into pools for other scheduler reasons - am I missing somethign ?

The RPC component is there to ensure XenAPI still works.  In the libvirt driver, add_to_aggregate() is a noop.

So you can create an aggregate that can be linked to a hypervisor but also as a way to tag hosts


Thanks,
Phil




_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120920/a84b4708/attachment.html>