[openstack-dev] [Heat] Conditionals, was: New function: first_nonnull

Zane Bitter zbitter at redhat.com
Wed Nov 12 16:42:44 UTC 2014


On 12/11/14 10:10, Clint Byrum wrote:
> Excerpts from Zane Bitter's message of 2014-11-11 13:06:17 -0800:
>> 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 ;)
>>
>
> So far nobody has stepped up to defend me,

I'll defend you, but I can't defend the idea :)

> so I'll accept that maybe
> people do think it is crazy. What I'm really confused by is why we have
> a new weird ugly language like YAQL (sorry, it, like JQ, is hideous),

Agreed, and appealing to its similarity with Perl or PHP (or BASIC!) is 
probably not the way to win over Python developers :D

> and that would somehow be less crazy than a well known mature language
> that has always been meant for embedding such as javascript.

JS is a Turing-complete language, it's an entirely different kettle of 
fish to a domain-specific language that is inherently safe to interpret 
from user input. Sure, we can try to lock it down. It's a very tricky 
job to get right. (Plus it requires a new external dependency of unknown 
quality... honestly if you're going to embed a Turing-complete language, 
Python is a much more obvious choice than JS.)

> Anyway, I'd prefer YAQL over trying to get the intrinsic functions in
> HOT just right. Users will want to do things we don't expect. I say, let
> them, or large sections of the users will simply move on to something
> else.

The other side of that argument is that users are doing one of two 
things with data they have obtained from resources in the template:

1) Passing data to software deployments
2) Passing data to other resources

In case (1) they can easily transform the data into whatever format they 
want using their own scripts, running on their own server.

In case (2), if it's not easy for them to just do what they want without 
having to perform this kind of manipulation, we have failed to design 
good resources. And if we give people the tools to just paper over the 
problem, we'll never hear about it so we can correct it at the source, 
just launch a thousand hard-to-maintain hacks into the world.

cheers,
Zane.



More information about the OpenStack-dev mailing list