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)" <yud...@cisco.com> To: OpenStack Development Mailing List <openstack-dev@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev