Open Stack

On 10/29/13 at 04:05pm, Mike Spreitzer wrote:
>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.

Having Nova call into Heat is backwards IMO.  If there are specific 
pieces of information that Nova can expose, or API capabilities to help 
with orchestration/placement that Heat or some other service would like 
to use then let's look at that.  Nova has placement concerns that extend 
to finding a capable hypervisor for the VM that someone would like to 
boot, and then just slightly beyond.  If there are higher level 
decisions to be made about placement decisions I think that belongs 
outside of Nova, and then just tell Nova where to put it.


>
>Thanks,
>Mike

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