> From: Zane Bitter <zbit...@redhat.com> > To: openstack-dev@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
