<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 13, 2014 at 4:00 AM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Zane Bitter's message of 2014-11-12 08:42:44 -0800:<br>
<span class="">> On 12/11/14 10:10, Clint Byrum wrote:<br>
> > Excerpts from Zane Bitter's message of 2014-11-11 13:06:17 -0800:<br>
> >> On 11/11/14 13:34, Ryan Brown wrote:<br>
> >>> I am strongly against allowing arbitrary Javascript functions for<br>
> >>> complexity reasons. It's already difficult enough to get meaningful<br>
> >>> errors when you **** up your YAML syntax.<br>
> >><br>
> >> Agreed, and FWIW literally everyone that Clint has pitched the JS idea<br>
> >> to thought it was crazy ;)<br>
> >><br>
> ><br>
> > So far nobody has stepped up to defend me,<br>
><br>
> I'll defend you, but I can't defend the idea :)<br>
><br>
> > so I'll accept that maybe<br>
> > people do think it is crazy. What I'm really confused by is why we have<br>
> > a new weird ugly language like YAQL (sorry, it, like JQ, is hideous),<br>
><br>
> Agreed, and appealing to its similarity with Perl or PHP (or BASIC!) is<br>
> probably not the way to win over Python developers :D<br>
><br>
> > and that would somehow be less crazy than a well known mature language<br>
> > that has always been meant for embedding such as javascript.<br>
><br>
> JS is a Turing-complete language, it's an entirely different kettle of<br>
> fish to a domain-specific language that is inherently safe to interpret<br>
> from user input. Sure, we can try to lock it down. It's a very tricky<br>
> job to get right. (Plus it requires a new external dependency of unknown<br>
> quality... honestly if you're going to embed a Turing-complete language,<br>
> Python is a much more obvious choice than JS.)<br>
><br>
<br>
</span>There's a key difference though. Python was never designed to be run<br>
from untrusted sources. Javascript was _from the beginning_. There are<br>
at least two independent javascript implementations which both have been<br>
designed from the ground up to run code from websites in the local<br>
interpreter. From the standpoint of Heat, it would be even easier to do<br>
this.<br>
<br>
Perhaps I can carve out some of that negative-1000-days of free time I<br>
have and I can make it a resource plugin, with the properties being code<br>
and references to other resources, and the attributes being the return.<br>
<span class=""><br>
> > Anyway, I'd prefer YAQL over trying to get the intrinsic functions in<br>
> > HOT just right. Users will want to do things we don't expect. I say, let<br>
> > them, or large sections of the users will simply move on to something<br>
> > else.<br>
><br>
> The other side of that argument is that users are doing one of two<br>
> things with data they have obtained from resources in the template:<br>
><br>
> 1) Passing data to software deployments<br>
> 2) Passing data to other resources<br>
><br>
> In case (1) they can easily transform the data into whatever format they<br>
> want using their own scripts, running on their own server.<br>
><br>
> In case (2), if it's not easy for them to just do what they want without<br>
> having to perform this kind of manipulation, we have failed to design<br>
> good resources. And if we give people the tools to just paper over the<br>
> problem, we'll never hear about it so we can correct it at the source,<br>
> just launch a thousand hard-to-maintain hacks into the world.<br>
><br></span></blockquote><div><br></div><div>case (3) is trying to write a half useful template resource. With what we have<br>this is very difficult. I think for non-trivial templates people very quickly run<br>into the limitations of HOT.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
</span>I for one would rather serve the users than ourselves, and preventing<br>
them from papering over the problems so they have to whine at us is a<br>
self-serving agenda.<br>
<br>
As a primary whiner about Heat for a long time, I respect a lot that<br>
this development team _bends over backwards_ to respond to user<br>
requests. It's amazing that way.<br>
<br>
However, I think to grow beyond open source savvy, deeply integrated<br>
users like me, one has to let the users solve their own problems. They'll<br>
know that their javascript or YAQL is debt sometimes, and they can<br>
come to Heat's development community with suggestions like "If you had<br>
a coalesce function I wouldn't need to write it in javascript". But if<br>
you don't give them _something_, they'll just move on.<br></blockquote><div><br></div><div>Agree, I think we need to get this done. We can't just keep ignoring users when<br>they are begging for the same feature, because supposedly they are doing it wrong.<br></div><div><br></div><div>-Angus<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Anyway, probably looking further down the road than I need to, but<br>
please keep an open mind for this idea, as users tend to use tools that<br>
solve their problem _and_ get out of their way in all other cases.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>