On Thu, Nov 13, 2014 at 4:00 AM, Clint Byrum <cl...@fewbar.com> wrote:
> Excerpts from Zane Bitter's message of 2014-11-12 08:42:44 -0800: > > 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.) > > > > There's a key difference though. Python was never designed to be run > from untrusted sources. Javascript was _from the beginning_. There are > at least two independent javascript implementations which both have been > designed from the ground up to run code from websites in the local > interpreter. From the standpoint of Heat, it would be even easier to do > this. > > Perhaps I can carve out some of that negative-1000-days of free time I > have and I can make it a resource plugin, with the properties being code > and references to other resources, and the attributes being the return. > > > > 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. > > > case (3) is trying to write a half useful template resource. With what we have this is very difficult. I think for non-trivial templates people very quickly run into the limitations of HOT. > > I for one would rather serve the users than ourselves, and preventing > them from papering over the problems so they have to whine at us is a > self-serving agenda. > > As a primary whiner about Heat for a long time, I respect a lot that > this development team _bends over backwards_ to respond to user > requests. It's amazing that way. > > However, I think to grow beyond open source savvy, deeply integrated > users like me, one has to let the users solve their own problems. They'll > know that their javascript or YAQL is debt sometimes, and they can > come to Heat's development community with suggestions like "If you had > a coalesce function I wouldn't need to write it in javascript". But if > you don't give them _something_, they'll just move on. > Agree, I think we need to get this done. We can't just keep ignoring users when they are begging for the same feature, because supposedly they are doing it wrong. -Angus > > Anyway, probably looking further down the road than I need to, but > please keep an open mind for this idea, as users tend to use tools that > solve their problem _and_ get out of their way in all other cases. > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
