Open Stack

Stephen Gran <stephen.gran at theguardian.com> wrote on 09/27/2013 04:26:37 
AM:

> Maybe I'm missing something obvious, but I'm not convinced all that 
> logic belongs in Heat.  I would expect nova and related components to 
> expose grouping information (availability zones in nova, networks in 
> quantum, etc) and for end users to supply the "group by" information.

Yes, this additional policy information is not intended to inform 
infrastructure orchestration.  It is intended to inform something that I 
have been calling holistic infrastructure scheduling and others have 
called things like unified resource placement and smart resource 
placement.  I frame it as an extension to Heat templates because this 
policy information needs to be added to a statement about a whole 
pattern/template/topology and Heat templates are the language we have for 
such things.  The idea is that holistic infrastructure scheduling comes 
before infrastructure orchestration; by the time infrastructure 
orchestration happens, the policy information has been handled and removed 
(or, possibly, encapsulated in some way for downstream processing --- but 
that's another story I am not trying to broach yet).

I have been discussing this outline here under the subject "Bringing 
things together for Icehouse" (
http://lists.openstack.org/pipermail/openstack-dev/2013-September/015118.html
), in the scheduler subgroup and heat weekly IRC meetings, and have a 
design summit proposal (http://summit.openstack.org/cfp/details/113).


> I think that your use case for anti-collocation (which is a very good 
> and important use case, don't get me wrong) is covered by using 
> availability zones/cells/regions and so on as they are, and doesn't 
> require much logic internal to Heat beyond obeying the constraint 
> specified by a user.

If there are five racks in the system and I want to say that two VMs 
should be placed on different racks, how do I say that with AZs without 
being overly specific?

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