[openstack-dev] [scheduler] [heat] Policy specifics

Mike Spreitzer mspreitz at us.ibm.com
Fri Sep 27 17:23:14 UTC 2013


Stephen Gran <stephen.gran at theguardian.com> wrote on 09/27/2013 10:46:09 
AM:

> If the admins of the openstack install wanted users to be able to select 

> placement by rack, surely the availability zones would be rack1 - rack5 
> ?  In this case, the user would write:
> 
>    "Resources" : {
>      "MyASG" : {
>        "Type" : "AWS::AutoScaling::AutoScalingGroup",
>        "Properties" : {
>          "AvailabilityZones" : { "Fn::GetAZs" : ""},
>          "MinSize" : "2",
>    "DesiredSize": "2",
>          "MaxSize" : "2",
>        }
>      },
> 
> This should naturally implement placement as spread evenly across AZs.

You have added that "DesiredSize" property, to convey the idea of 
spreading across at least some number (2 in this case) of AZs, right? That 
is, it is not functionality in today's Nova, rather something we could 
add.

What if the cloud in question has several levels of structure available, 
and the admins want users to be able to spread at any of the available 
levels?

> I think maybe this is where I think my disagreement is.  Heat should be 
> able to express a user preference for placement, but only within the 
> bounds of the policy already created by the admins of the nova install. 
>   To have Heat have more knowledge than what is available via the nova 
> API seems overcomplicated and fragile to me.  If the nova API should 
> grow some extensions to make more complicated placement algorithms 
> available, then that's an argument that might have legs.

I am trying to find a way to introduce holistic infrastructure scheduling, 
whose purpose in life is to do what Nova, Cinder, etc can not do on their 
own.  (Making Nova, Cinder, and friends more capable on their own is also 
good, and complements what I am advocating.)  Yes, this requires some more 
visibility and control from those individual services.  Those needs have 
come up in vague ways in the discussion so far, and I plan to write 
something specific.

I am distinctly NOT advocating mixing holistic infrastructure scheduling 
up with infrastructure orchestration.  I think holistic infrastructure 
scheduling happens prior to infrastructure orchestration.  The more 
debatable question is the ordering with respect to the preparatory stage 
of software orchestration.  Another complicating factor is what happens 
when the infrastructure orchestration calls out to something that makes a 
nested stack.

Regards,
Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130927/b76ee58c/attachment.html>


More information about the OpenStack-dev mailing list