On 11/11/14 13:34, Ryan Brown wrote:
I am strongly against allowing arbitrary Javascript functions for
complexity reasons. It's already difficult enough to get meaningful
errors when you **** up your YAML syntax.

Agreed, and FWIW literally everyone that Clint has pitched the JS idea to thought it was crazy ;)

I don't really like YAQL either though. It looks like line noise to me. From the beginning we've tried to have the absolute minimum number of intrinsic functions in HOT. I would much prefer to resurrect the previous proposal for adding conditionals and then see what is still missing than to just dive straight in to embedding a whole other language in HOT.

AIUI the functionality many users would look to use Javascript
embed-ability for would be better served either by something like yaql,
or by making vendored HOT functions possible.

Vendored HOT would look something like "X-Vendor::YourNamespace" and
functions could be managed similarly to resource plugins (stevedore).
It's a very rough idea, but I like it much better than adding Javascript.

That already existed at one point. We ripped out the plugin part during Juno in favour of tying the intrinsic functions available to a template format, so that vendoring HOT with new intrinsic functions also requires (or at least suggests) changing the template format version string, to allow Heat can detect immediately when you are using an unsupported template format.

That said it still basically works, but the real issue is that it's under the control of the operator and not the template author.


OpenStack-dev mailing list

Reply via email to