Open Stack

On Wed, Mar 02, 2016 at 05:40:20PM -0500, Zane Bitter wrote:
> 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.

Yeah, this won't work if you attempt to do the map/index lookup in the
top-level template where the ResourceGroup is defined, but it *does* work
if you pass both the map and the index into the nested stack, e.g something
like this (untested):

$ cat rg_az_map.yaml
heat_template_version: 2015-04-30

parameters:
  az_map:
    type: json
    default:
      '0': az1
      '1': az2

resources:
 AGroup:
    type: OS::Heat::ResourceGroup
    properties:
      count: 2
      resource_def:
        type: server_mapped_az.yaml
        properties:
          availability_zone_map: {get_param: az_map}
          index: '%index%'

$ cat server_mapped_az.yaml
heat_template_version: 2015-04-30

parameters:
  availability_zone_map:
    type: json
  index:
    type: string

resources:
 server:
    type: OS::Nova::Server
    properties:
      image: the_image
      flavor: m1.foo
      availability_zone: {get_param: [availability_zone_map, {get_param: index}]}

FWIW we already use this technique in some TripleO templates, and it works
pretty well.

https://github.com/openstack/tripleo-heat-templates/blob/master/network/ports/external_from_pool.yaml#L35

Steve