Open Stack

On Wed, Nov 12, 2014 at 9:33 PM, Alexis Lee <alexisl at hp.com> wrote:

> Zane Bitter said on Tue, Nov 11, 2014 at 04:06:17PM -0500:
> > FWIW literally everyone that Clint has pitched the JS
> > idea to thought it was crazy ;)
>
> +1
>
> > YAQL ... looks like line noise to me
>
> YAML representing function call stacks (an AST) looks pretty bad to me
> :)
>
> The YAQL doc is not great at the moment but the language is not
> difficult. It's pretty similar to XPath, jq and JSP EL, i.e. dotted
> syntax with square brackets for attribute selection and slicing. That's
> also pretty similar to Python btw.
>
> Is there another expression language you prefer?
>
> > From the beginning we've tried to have the absolute minimum
> > number of intrinsic functions in HOT.
>
> This is understandable but there are things I want to do (as an operator
> - like first_nonnull) which I cannot. The options as I see them:
>
>   * Add a bunch of operators and a LOT of functions
>   * Add a bunch of operators, a few functions and lambda
>   * Add a bunch of functions and use an expression language for
>     arithmetic, comparison etc
>   * Use an expression language for all complex processing
>


I think it's pretty clear we need something more powerful that adding
heaps of intrinsic functions, IMHO as long as we can prove it is safe
we should add yaql (it's nice that there would be a consistent user
experience
between these projects -mistral/heat/murano).

-Angus


> > I would much prefer to resurrect the previous proposal for adding
> > conditionals and then see what is still missing than to just dive
> > straight in to embedding a whole other language in HOT.
>
> Do you mean this? https://blueprints.launchpad.net/heat/+spec/intrinsics
> This only provides string equality and boolean logic. It's insufficient
> to implement first_nonnull for example.
>
> I'd like to emphasise that we don't have to offer the whole YAQL stdlib
> in HOT initially. We can use it just for its operator suite and a few
> key functions then add others as usecases are discovered.
>
>
+1


> > On 11/11/14 13:34, Ryan Brown wrote:
> > >Vendored HOT
> > the real issue is that it's under the control of the operator and not
> > the template author.
>
> Yep, the solution has to be through the template as that's 99% of the
> user interface.
>
>
> Alexis
> --
> Nova Engineer, HP Cloud.  AKA lealexis, lxsli.
>
> _______________________________________________
> 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/20141112/d901b585/attachment.html>