<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; "><div><br></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Alex Glikson <<a href="mailto:GLIKSON@il.ibm.com">GLIKSON@il.ibm.com</a>><br><span style="font-weight:bold">Reply-To: </span> "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br><span style="font-weight:bold">Date: </span> Wednesday, October 30, 2013 12:32 AM<br><span style="font-weight:bold">To: </span> "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br><span style="font-weight:bold">Subject: </span> Re: [openstack-dev] [nova][scheduler] Instance Group Model and APIs - Updated document with an example request payload<br></div><div><br></div><div><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div><tt><font size="2">Andrew Laski <<a href="mailto:andrew.laski@rackspace.com">andrew.laski@rackspace.com</a>> wrote on 29/10/2013 11:14:03 PM:<br>
> [...]</font></tt> <br><tt><font size="2">> Having Nova call into Heat is backwards IMO. If there are specific
<br>
> pieces of information that Nova can expose, or API capabilities to help <br>
> with orchestration/placement that Heat or some other service would like <br>
> to use then let's look at that. Nova has placement concerns that extend <br>
> to finding a capable hypervisor for the VM that someone would like to <br>
> boot, and then just slightly beyond.</font></tt> <br><br><tt><font size="2">+1</font></tt> <br></div></div></span><div><br></div><div>[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.</div><span id="OLK_SRC_BODY_SECTION"><div><div><br><tt><font size="2">> If there are higher level <br>
> decisions to be made about placement decisions I think that belongs <br>
> outside of Nova, and then just tell Nova where to put it.</font></tt> <br><br><tt><font size="2">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?</font></tt> <br><br><tt><font size="2">Regards,</font></tt> <br><tt><font size="2">Alex</font></tt> <br></div></div></span></body></html>