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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
