Open Stack

Alex Glikson <GLIKSON at il.ibm.com> wrote on 10/29/2013 03:37:41 AM:

> 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.

Remember we are just starting on the roadmap.  Nova in Icehouse, holistic 
later.

> 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?

I am aiming for the holistic future, and Yathi copied that from an example 
I drew with the holistic future in mind.  While we are only addressing 
Nova, I think a network reachability policy is inapproprite.

> 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? 

You raised a few interesting issues.

1. Heat already has a way to specify resources, I do not see why we should 
invent another.

2. Should Nova call Heat to do the orchestration?  I would like to see an 
example where ordering is an issue.  IMHO, since OpenStack already has a 
solution for creating resources in the right order, I do not see why we 
should invent another.

Thanks,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/95d8c10a/attachment.html>