<font size=2 face="sans-serif">Nice example.. I think this is certainly
a step in the right direction. However, I am a bit lost when trying to
figure out how this kind of API (which makes perfect sense at the conceptual
level) can be implemented. IMO, when we make the attempt to design the
actual implementation that would be provided behind the API, with all the
inter-dependencies etc, it might have significant impact on the API itself.
Couple of specific questions.</font>
<br>
<br><font size=2 face="sans-serif">1. I assume that the motivation for
rack-level anti-affinity is to survive a rack failure. Is this indeed the
case?</font>
<br><font size=2 face="sans-serif">This is a very interesting and important
scenario, but I am curious about your assumptions regarding all the other
OpenStack resources and services in this respect. Recovering stateless
VMs is probably the easiest part, that can be done fairly quickly without
instance groups (of course, not with close to zero RTO that can be achieved
with this approach -- but probably few minutes, with some level of automation
on top), so it would be great to understand how this fits an overall approach
to recovery from a rack failure, basically referring to resources and metadata
of all the (other) OpenStack services (storage, network, images, etc).
For example, if we can claim that we already can achieve rack-level HA
for the entire environment with RTO of 1 hour, and with instance groups
we improve it to 1 minute -- this would be very impressive!</font>
<br>
<br><font size=2 face="sans-serif">2. What exactly do you mean by "network
reachibility" between the two groups? Remember that we are in Nova
(at least for now), so we don't have much visibility to the topology of
the physical or virtual networks. Do you have some concrete thoughts on
how such policy can be enforced, in presence of potentially complex environment
managed by Neutron?</font>
<br>
<br><font size=2 face="sans-serif">3. The JSON somewhat reminds me the
interface of Heat, and I would assume that certain capabilities that would
be required to implement it would be similar too. What is the proposed
approach to 'harmonize' between the two, in environments that include Heat?
What would be end-to-end flow? For example, who would do the orchestration
of individual provisioning steps? Would "create" operation delegate
back to Heat for that? Also, how other relationships managed by Heat (e.g.,
links to storage and network) would be incorporated in such an end-to-end
scenario?</font>
<br>
<br><font size=2 face="sans-serif">Indeed, would be great if we could spend
some time at the summit to discuss the implementation details (and not
just the API).</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br><font size=2 face="sans-serif">Alex<br>
</font>
<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 <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 08:49 AM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">[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">The Instance Group API document is now
updated with a simple example request payload of a nested group, and some
description of how the API implementation should handle the registration
of the components of a nested instance group. </font>
<br><a href="https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit"><font size=2 color=blue face="Calibri"><u>https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit</u></font></a><font size=2 face="Calibri">
</font>
<br>
<br><font size=2 face="Calibri">Hope we will have a good API design session
at the summit, and also continue the discussion face-to-face over there.
</font>
<br>
<br><font size=2 face="Calibri">Thanks,</font>
<br><font size=2 face="Calibri">Yathi. </font>
<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>