Open Stack

On Nov 12, 2014, at 10:42 AM, Zane Bitter <zbitter at redhat.com>
 wrote:

> 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.

I disagree with this last bit. Having some manner of data manipulation facility as part of the template language doesn't mean the resources are badly designed or implemented, it just means that users have constraints that we don't directly address. Having something more general purpose (whatever it may be) seems like a longer term and more maintainable solution to me than eternal tail chasing where 1000 specific intrinsic functions bloom. IMO, intrinsics have a place, but supporting something like YAQL (or whatever) seems like a general solution to a lot of common problems our users come up against.

As for "hard-to-maintain hacks", isn't that what drives a lot of our users to ask for these sorts of solutions in the first place? If doing something via YAQL is perceived by a user as some sub-optimal hack for their use case, I see no reason for that to be any less visible than any other pain point or usability issue we have.