Open Stack

On Thu, Nov 13, 2014 at 4:00 AM, Clint Byrum <clint at 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 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/a30c2ab3/attachment.html>