From: Alex Glikson <glik...@il.ibm.com<mailto:glik...@il.ibm.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, October 30, 2013 12:32 AM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [nova][scheduler] Instance Group Model and APIs - Updated document with an example request payload
Andrew Laski <andrew.la...@rackspace.com<mailto:andrew.la...@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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
