[openstack-dev] [Heat] Re-evaluate conditions specification

Thomas Herve therve at redhat.com
Thu Mar 31 11:57:40 UTC 2016

On Thu, Mar 31, 2016 at 11:39 AM, Qiming Teng
<tengqim at linux.vnet.ibm.com> wrote:
> On Thu, Mar 31, 2016 at 10:40:33AM +0200, Thomas Herve wrote:
>> Hi all,
>> As the patches for conditions support are incoming, I've found
>> something in the code (and the spec) I'm not really happy with. We're
>> creating a new top-level section in the template called "conditions"
>> which holds names that can be reused for conditionally creating
>> resource.
>> While it's fine and maps to what AWS does, I think it's a bit
>> short-sighted and limited. What I have suggested in the past is to
>> have a "variables" (or whatever you want to call it) section, where
>> one can declare names and values. Then we can add an intrinsic
>> function to retrieve data from there, and use that for examples for
>> conditions.
>> It solves that particular issue, and it opens some interesting
>> possibilities for reducing duplication in the template, as we could
>> build arbitrary values out of parameters or attributes that can then
>> be reused several times.
>> Thoughts?
> Though not very excited by the current approach, I'm still a little bit
> concerned about the extent to which we are extending the 'conditionals'
> support. This is not an easy call given that we don't want HOT to become
> a programming language.
> A long time ago, we have a proposal from sdake. That one was stagnated
> for ever. If we want to revisit this topic from step 0, we may as well
> need to define the scope cleanly. For example, are we gonna support some
> idioms for 'if, elif' only or we are introducing 'switch/case' also?
> Are we introducing a boolean evaluator that can be applied to all data
> types so that we get grammar completeness?
> Are we gonna support logical operators as well? e.g. AND, OR, NOT?
> Would this mean we are introducing some "reserved words" to HOT, or some
> more builtin functions?
> If these are to be modeled as functions, do we still want them to be
> implemented at client side, as we do for 'get_file'?

That's an interesting conversation, but not the one I was expecting to
trigger. I believe
answers most of the questions you're asking. I mostly try to adjust
one point of that spec already approved.


More information about the OpenStack-dev mailing list