Open Stack

From: Alex Glikson <GLIKSON at il.ibm.com<mailto:GLIKSON at il.ibm.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Wednesday, October 30, 2013 12:32 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [nova][scheduler] Instance Group Model and APIs - Updated document with an example request payload

Andrew Laski <andrew.laski at rackspace.com<mailto:andrew.laski at rackspace.com>> wrote on 29/10/2013 11:14:03 PM:
> [...]
> Having Nova call into Heat is backwards IMO.  If there are specific
> pieces of information that Nova can expose, or API capabilities to help
> with orchestration/placement that Heat or some other service would like
> to use then let's look at that.  Nova has placement concerns that extend
> to finding a capable hypervisor for the VM that someone would like to
> boot, and then just slightly beyond.

+1

[Gary Kotton] When we proposed the initial VM ensembles this was one of the option that was considered. The guys from Heat did not like this approach. I like the idea and see it as something plumbable, for example like the networking module. This can be a pluggable scheduling interface that has a global picture of all of the systems resources.

>  If there are higher level
> decisions to be made about placement decisions I think that belongs
> outside of Nova, and then just tell Nova where to put it.

I wonder whether it is possible to find an approach that takes into account cross-resource placement considerations (VM-to-VM communicating over the application network, or VM-to-volume communicating over storage network), but does not require delivering all the intimate details of the entire environment to a single place -- which probably can not be either of Nova/Cinder/Neutron/etc.. but can we still use the individual schedulers in each of them with partial view of the environment to drive a placement decision which is consistently better than random?

Regards,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131030/acc8fb43/attachment.html>