<font size=2 face="sans-serif">If we envision the main benefits only after
(parts of) this logic moves outside of Nova (and starts addressing other
resources) -- would it be still worth maintaining an order of 5K LOC in
Nova to support this feature? Why not going for the 'ultimate' solution
in the first place then, keeping in Nova only the mandatory enablement
(TBD)?</font>
<br><font size=2 face="sans-serif">Alternatively, if we think that there
is value in having this just in Nova -- would be good to understand the
exact scenarios which do not require awareness of other resources (and
see if they are important enough to maintain those 5K LOC), and how exactly
this can gradually evolve into the 'ultimate' solution.</font>
<br><font size=2 face="sans-serif">Or am I missing something?</font>
<br>
<br><font size=2 face="sans-serif">Alex</font>
<br>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Yathiraj Udupi
(yudupi)" <yudupi@cisco.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"OpenStack Development
Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">29/10/2013 11:46 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [openstack-dev]
[nova][scheduler] Instance Group Model and APIs - Updated document with
an example request payload</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=2 face="Calibri">Thanks Alex, Mike, Andrew, Russel for your
comments. This ongoing API discussion started in our scheduler meetings,
as a first step to tackle in the Smarter resource placement ideas - See
the doc for reference - </font><a href=https://docs.google.com/document/d/1IiPI0sfaWb1bdYiMWzAAx0HYR6UqzOan_Utgml5W1HI/edit><font size=2 color=blue face="Calibri"><u>https://docs.google.com/document/d/1IiPI0sfaWb1bdYiMWzAAx0HYR6UqzOan_Utgml5W1HI/edit</u></font></a><font size=2 face="Calibri">
This roadmap calls for a unified resource placement decisions to
be taken covering resources across services, starting from a complete topology
request with all the necessary nodes/instances/resources, their connections,
and the policies. </font>
<br>
<br><font size=2 face="Calibri">However we agreed that we will first address
the defining of the required APIs, and start the effort to make this happen
within Nova, using VM instances groups, with policies. </font>
<br><font size=2 face="Calibri">Hence this proposal for the instance groups.
</font>
<br>
<br><font size=2 face="Calibri">The entire group needs to be placed as
a whole, at least the first step is to find an ideal placement choices
for the entire group. Once the placement has been identified (using
a smart resource placement engine that addresses solving the entire group),
we then focus on ways to schedule them as a whole. This is not part
of the API discussion, however important for the smart resource placement
ideas. This definitely involves concepts such as reservation, etc.
Heat or Heat APIs could be a choice to enable the final orchestration,
but I am not commenting on that here.</font>
<br>
<br><font size=2 face="Calibri">The APIs effort here is an attempt to provide
clean interfaces now to be able to represent this instance group, and save
them, and also define apis to create them. The actual implementation
will have to rely on one or more services to - 1. to make the resource
placement decisions, 2. then actually provision them, orchestrate them
in the right order, etc. </font>
<br>
<br><font size=2 face="Calibri">The placement decisions itself can happen
in a module that can be a separate service, and can be reused by different
services, and it also needs to have a global vision of all the resources.
(Again all of this part of the scope of smart resource placement
topic). </font>
<br>
<br><font size=2 face="Calibri">Thanks,</font>
<br><font size=2 face="Calibri">Yathi. </font>
<br>
<br>
<br><font size=2 face="Calibri">On 10/29/13, 2:14 PM, "Andrew Laski"
<</font><a href=mailto:andrew.laski@rackspace.com><font size=2 color=blue face="Calibri"><u>andrew.laski@rackspace.com</u></font></a><font size=2 face="Calibri">>
wrote:</font>
<br>
<br><font size=2 face="Calibri">On 10/29/13 at 04:05pm, Mike Spreitzer
wrote:</font>
<br><font size=2 face="Calibri">Alex Glikson <</font><a href=mailto:GLIKSON@il.ibm.com><font size=2 color=blue face="Calibri"><u>GLIKSON@il.ibm.com</u></font></a><font size=2 face="Calibri">>
wrote on 10/29/2013 03:37:41 AM:</font>
<br>
<br><font size=2 face="Calibri">1. I assume that the motivation for rack-level
anti-affinity is to</font>
<br><font size=2 face="Calibri">survive a rack failure. Is this indeed
the case?</font>
<br><font size=2 face="Calibri">This is a very interesting and important
scenario, but I am curious</font>
<br><font size=2 face="Calibri">about your assumptions regarding all the
other OpenStack resources</font>
<br><font size=2 face="Calibri">and services in this respect.</font>
<br>
<br><font size=2 face="Calibri">Remember we are just starting on the roadmap.
Nova in Icehouse, holistic</font>
<br><font size=2 face="Calibri">later</font>
<br>
<br><font size=2 face="Calibri">2. What exactly do you mean by "network
reachibility" between the</font>
<br><font size=2 face="Calibri">two groups? Remember that we are in Nova
(at least for now), so we</font>
<br><font size=2 face="Calibri">don't have much visibility to the topology
of the physical or</font>
<br><font size=2 face="Calibri">virtual networks. Do you have some concrete
thoughts on how such</font>
<br><font size=2 face="Calibri">policy can be enforced, in presence of
potentially complex</font>
<br><font size=2 face="Calibri">environment managed by Neutron?</font>
<br>
<br><font size=2 face="Calibri">I am aiming for the holistic future, and
Yathi copied that from an example</font>
<br><font size=2 face="Calibri">I drew with the holistic future in mind.
While we are only addressing</font>
<br><font size=2 face="Calibri">Nova, I think a network reachability policy
is inapproprite.</font>
<br>
<br><font size=2 face="Calibri">3. The JSON somewhat reminds me the interface
of Heat, and I would</font>
<br><font size=2 face="Calibri">assume that certain capabilities that would
be required to implement</font>
<br><font size=2 face="Calibri">it would be similar too. What is the proposed
approach to</font>
<br><font size=2 face="Calibri">'harmonize' between the two, in environments
that include Heat? What</font>
<br><font size=2 face="Calibri">would be end-to-end flow? For example,
who would do the</font>
<br><font size=2 face="Calibri">orchestration of individual provisioning
steps? Would "create"</font>
<br><font size=2 face="Calibri">operation delegate back to Heat for that?
Also, how other</font>
<br><font size=2 face="Calibri">relationships managed by Heat (e.g., links
to storage and network)</font>
<br><font size=2 face="Calibri">would be incorporated in such an end-to-end
scenario?</font>
<br>
<br><font size=2 face="Calibri">You raised a few interesting issues.</font>
<br>
<br><font size=2 face="Calibri">1. Heat already has a way to specify resources,
I do not see why we should</font>
<br><font size=2 face="Calibri">invent another.</font>
<br>
<br><font size=2 face="Calibri">2. Should Nova call Heat to do the orchestration?
I would like to see an</font>
<br><font size=2 face="Calibri">example where ordering is an issue. IMHO,
since OpenStack already has a</font>
<br><font size=2 face="Calibri">solution for creating resources in the
right order, I do not see why we</font>
<br><font size=2 face="Calibri">should invent another.</font>
<br>
<br><font size=2 face="Calibri">Having Nova call into Heat is backwards
IMO. If there are specific </font>
<br><font size=2 face="Calibri">pieces of information that Nova can expose,
or API capabilities to help </font>
<br><font size=2 face="Calibri">with orchestration/placement that Heat
or some other service would like </font>
<br><font size=2 face="Calibri">to use then let's look at that. Nova
has placement concerns that extend </font>
<br><font size=2 face="Calibri">to finding a capable hypervisor for the
VM that someone would like to </font>
<br><font size=2 face="Calibri">boot, and then just slightly beyond. If
there are higher level </font>
<br><font size=2 face="Calibri">decisions to be made about placement decisions
I think that belongs </font>
<br><font size=2 face="Calibri">outside of Nova, and then just tell Nova
where to put it.</font>
<br>
<br>
<br>
<br><font size=2 face="Calibri">Thanks,</font>
<br><font size=2 face="Calibri">Mike</font>
<br>
<br><font size=2 face="Calibri">_______________________________________________</font>
<br><font size=2 face="Calibri">OpenStack-dev mailing list</font>
<br><a href="mailto:OpenStack-dev@lists.openstack.org"><font size=2 color=blue face="Calibri"><u>OpenStack-dev@lists.openstack.org</u></font></a>
<br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><font size=2 color=blue face="Calibri"><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a>
<br>
<br>
<br><font size=2 face="Calibri">_______________________________________________</font>
<br><font size=2 face="Calibri">OpenStack-dev mailing list</font>
<br><a href="mailto:OpenStack-dev@lists.openstack.org"><font size=2 color=blue face="Calibri"><u>OpenStack-dev@lists.openstack.org</u></font></a>
<br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><font size=2 color=blue face="Calibri"><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a>
<br><tt><font size=2>_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br>