[openstack-dev] [magnum][heat] spawn a group of nodes on different availability zones

Zane Bitter zbitter at redhat.com
Wed Mar 2 22:40:20 UTC 2016


On 02/03/16 05:50, Mathieu Velten wrote:
> Hi all,
>
> I am looking at a way to spawn nodes in different specified
> availability zones when deploying a cluster with Magnum.
>
> Currently Magnum directly uses predefined Heat templates with Heat
> parameters to handle configuration.
> I tried to reach my goal by sticking to this model, however I couldn't
> find a suitable Heat construct that would allow that.
>
> Here are the details of my investigation :
> - OS::Heat::ResourceGroup doesn't allow to specify a list as a variable
> that would be iterated over, so we would need one ResourceGroup by AZ
> - OS::Nova::ServerGroup only allows restriction at the hypervisor level
> - OS::Heat::InstanceGroup has an AZs parameter but it is marked
> unimplemented , and is CFN specific.
> - OS::Nova::HostAggregate only seems to allow adding some metadatas to
> a group of hosts in a defined availability zone
> - repeat function only works inside the properties section of a
> resource and can't be used at the resource level itself, hence
> something like that is not allowed :
>
> resources:
>    repeat:
>      for_each:
>        <%az%>: { get_param: availability_zones }
>      template:
>        rg-<%az%>:
>          type: OS::Heat::ResourceGroup
>          properties:
>            count: 2
>            resource_def:
>              type: hot_single_server.yaml
>              properties:
>                availability_zone: <%az%>
>
>
> The only possibility that I see is generating a ResourceGroup by AZ,
> but it would induce some big changes in Magnum to handle
> modification/generation of templates.
>
> Any ideas ?

This is a long-standing missing feature in Heat. There are two 
blueprints for this (I'm not sure why):

https://blueprints.launchpad.net/heat/+spec/autoscaling-availabilityzones-impl
https://blueprints.launchpad.net/heat/+spec/implement-autoscalinggroup-availabilityzones

The latter had a spec with quite a lot of discussion:

https://review.openstack.org/#/c/105907

And even an attempted implementation:

https://review.openstack.org/#/c/116139/

which was making some progress but is long out of date and would need 
serious work to rebase. The good news is that some of the changes I made 
in Liberty like https://review.openstack.org/#/c/213555/ should 
hopefully make it simpler.

All of which is to say, if you want to help then I think it would be 
totally do-able to land support for this relatively early in Newton :)


Failing that, the only think I can think to try is something I am pretty 
sure won't work: a ResourceGroup with something like:

   availability_zone: {get_param: [AZ_map, "%i"]}

where AZ_map looks something like {"0": "az-1", "1": "az-2", "2": 
"az-1", ...} and you're using the member index to pick out the AZ to use 
from the parameter. I don't think that works (if "%i" is resolved after 
get_param then it won't, and I suspect that's the case) but it's worth a 
try if you need a solution in Mitaka.

cheers,
Zane.



More information about the OpenStack-dev mailing list