[openstack-dev] [Heat] Re-evaluate conditions specification
tengqim at linux.vnet.ibm.com
Thu Mar 31 09:39:40 UTC 2016
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
> 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
> 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.
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'?
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev