Open Stack

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.

1. I assume that the motivation for rack-level anti-affinity is to survive 
a rack failure. Is this indeed the case?
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!

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?

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?

Indeed, would be great if we could spend some time at the summit to 
discuss the implementation details (and not just the API).

Regards,
Alex




From:   "Yathiraj Udupi (yudupi)" <yudupi at cisco.com>
To:     OpenStack Development Mailing List 
<openstack-dev at lists.openstack.org>, 
Date:   29/10/2013 08:49 AM
Subject:        [openstack-dev] [nova][scheduler] Instance Group Model and 
APIs - Updated document with an example request payload



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. 
https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit 


Hope we will have a good API design session at the summit, and also 
continue the discussion face-to-face over there. 

Thanks,
Yathi. 
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/230e2e7b/attachment.html>