Open Stack

> From: Zane Bitter <zbitter at redhat.com>
> To: openstack-dev at lists.openstack.org
> Date: 03/04/2014 22:09
> Subject: Re: [openstack-dev] [Heat] Some thoughts on the mapping section
>
> On 03/04/14 03:21, Thomas Herve wrote:
> >> Speaking of offering options for selection, there is another proposal
on
> >> >adding conditional creation of resources [3], whose use case to
enable
> >> >or disable a resource creation (among others).  My perception is that
> >> >these are all relevant enhancements to the reusability of HOT
templates,
> >> >though I don't think we really need very sophisticated combinatory
> >> >conditionals.
> > I think that's interesting that you mentioned that, because Zane
> talked about a "variables" section, which would encompass what
> "conditions" and "mappings" mean. That's why we're discussing
> extensively about those design points, to see where we can be a bit
> more generic to handle more use cases.
>
> There was some discussion in the review[1] of having an if/then function
> (equivalent of the ternary ?: operator in C) for calculating variable...
> on reflection that is nothing more than a dumbed down version of
> Fn::Select in CloudFormation (which we have no equivalent to in HOT) in
> which the only possible index values are "true" and "false".
>
> The differences between Fn::Select and Fn::FindInMap are:
>
> 1) The bizarre double-indirect lookup, of course; and
> 2) The actual mappings are defined once in a single place, rather than
> everywhere you need to access them.
>
> I think we're all agreed that (1) is undesirable in itself. It occurs to
> me that the existence of a variables section could render (2) moot also
> (since you could calculate the result in one place, and just reference
> it from there on).
>
> So if we had the variables section, we probably no longer need to
> consider a mapping section and a replacement for Fn::FindInMap, just a
> replacement for Fn::Select that could also cover the if/then use case.
>
> Thoughts?

+1 for solving this in one place and coming up with such a solution that
introduces just one new "thing" to solve problems that are addressed with
two different things in CFN.

Regards,
Thomas

>
> cheers,
> Zane.
>
> [1] https://review.openstack.org/84468
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>