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