Open Stack

Will be very interesting to see how this plays out.
FYI, yql (a thing yahoo uses a-lot of, internally and externally) has this kind of functionality built-in.
https://developer.yahoo.com/yql/guide/yql-execute-chapter.html
I am unaware of any python version of a javascript engine that has rate/execution limiting and such[2], so I'm not sure how feasible this is without switching languages (to java using rhino[3] or one of the firefox monkey engines or chromes engine...).

It would though be neat to expose javascript functions to heat so that people could extend heat where they felt they needed to and 'glue' together there various javascript functions into a larger orchestration template that heat manages (and/or use native heat functionality that exists). That would seem like a good mix of functionality for people to have (and enables more advanced users); although it does of course introduce a bunch of complexity (first being where does this javascript code get ran, where is it stored...).

[2] https://developer.yahoo.com/yql/guide/yql-execute-intro-ratelimits.html[3] http://en.wikipedia.org/wiki/Rhino_%28JavaScript_engine%29

-Josh

     From: Clint Byrum <clint at fewbar.com>
 To: openstack-dev <openstack-dev at lists.openstack.org> 
 Sent: Wednesday, November 12, 2014 10:00 AM
 Subject: Re: [openstack-dev] [Heat] Conditionals, was: New function: first_nonnull
   
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.
> 

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.

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 at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141113/3fa9bb71/attachment.html>