Open Stack

Excerpts from Fox, Kevin M's message of 2015-12-15 17:21:13 -0800:
> the one thing as an Op I'd like to see avoided is having the template language be Turing complete. When I'm provisioning heat-engines its much easier if you know how many you need when the user can't force them to spin in an infinite loop or other such nasties. I think jinja maybe manages to do that, but I'm not totally sure. I'd think javascript woudln't though. AWS's conditionals are very basic and also should be predictable halting wise. yaql might be a good compromise between power and restrictedness.

Either give people the power, or don't. But going half-way and inventing
new things like YAQL is just going to frustrate users as they become more
sophisticated and realize it isn't the droid they're looking for. By then
they're invested, and will likely be forced back into templating their
templates while they wait for slightly more power to land in HOT. This
feels a lot like the way PHP took over the world: as the world gained
software engineering sophistication, they recoiled in horror and could
do nothing about it. Nobody wants to be responsible for making Heat the
PHP of orchestration systems, right?

The nice thing about those declared conditions is they are _SIMPLE_
and they are definitely not turing complete. They remind me of Ansible's
"when:". And likewise, I think a "with_items:" could probably be added
too to allow the two to work together without needing a turing complete
language to augment things server side.

But, if there are a ton of users clamoring for complicated server side
processing of their templates.. I would go all the way and maybe treat it
like AWS's lambda service... a thing unto itself that Heat just happens
to use.