Thank you both for your answers !
Indeed I need it sooner rather than later (as usual :) ) so the Newton
release is a bit too far away.
In the meantime I just test your solution with the index and the map
and it works great !
I'll use that for now, and we will discuss taking over the Heat bp
internally.
Regards,
Mathieu
Le jeudi 03 mars 2016 à 08:57 +0000, Steven Hardy a écrit :
> 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-availabilit
> > yzones-impl
> > https://blueprints.launchpad.net/heat/+spec/implement-autoscalinggr
> > oup-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/netwo
> rk/ports/external_from_pool.yaml#L35
>
> Steve
>
> _____________________________________________________________________
> _____
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
