On Thu, Nov 13, 2014 at 4:00 AM, Clint Byrum 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 strong
lint Byrum
To: openstack-dev
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 Zan
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
> >>> com
On Nov 12, 2014, at 10:42 AM, Zane Bitter
wrote:
> 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. I
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
My point is that quoting problem do exists probably but it exists even
without YAQL being used anywhere.
For example consider Mistral workbook containing value: { get_attr:
[my_instance, first_address] }. get_attr in Mistral may have nothing to to
with Heat's get_attr and even if it is it may be ju
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.
>
> A
On 12/11/14 08:24, Stan Lagun wrote:
On Wed, Nov 12, 2014 at 3:50 PM, Zane Bitter mailto:zbit...@redhat.com>> wrote:
It's actually potentially horrible, because you introduce potential
quoting issues when you embed mistral workbooks in Heat templates or
pass Heat templates to Murano
On 11/12/2014 07:50 AM, Zane Bitter wrote:
> On 12/11/14 06:48, Angus Salkeld wrote:
>> (it's nice that there would be a consistent user experience
>> between these projects -mistral/heat/murano).
>
> It's actually potentially horrible, because you introduce potential
> quoting issues when you e
On Wed, Nov 12, 2014 at 3:50 PM, Zane Bitter wrote:
> It's actually potentially horrible, because you introduce potential
> quoting issues when you embed mistral workbooks in Heat templates or pass
> Heat templates to Murano.
Could you please give an example of template with such issue?
Also no
On 12/11/14 06:48, Angus Salkeld wrote:
(it's nice that there would be a consistent user experience
between these projects -mistral/heat/murano).
It's actually potentially horrible, because you introduce potential
quoting issues when you embed mistral workbooks in Heat templates or
pass Heat
On 12/11/14 06:33, Alexis Lee wrote:
>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/intrins
On Wed, Nov 12, 2014 at 9:33 PM, Alexis Lee 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 stack
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 t
For those who don't know 100% of guys behind YAQL are also active OpenStack
contributors. During (early) Kilo cycle we plan to release YAQL version 1.0
on stackforge. This release is going to fix some flaws in early versions,
add some more flexibility and have very high UT coverage. There are at
le
On Wed, Nov 12, 2014 at 1:35 AM, Alexis Lee wrote:
> Alexis Lee said on Mon, Nov 10, 2014 at 05:34:13PM +:
> > How about we support YAQL expressions? https://github.com/ativelkov/yaql
> > Plus some HOFs (higher-order functions) like cond, map, filter, foldleft
> > etc?
>
> We could also use Y
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
On 11/11/2014 01:12 PM, Clint Byrum wrote:
> Excerpts from Alexis Lee's message of 2014-11-10 09:34:13 -0800:
>> Zane Bitter said on Fri, Nov 07, 2014 at 12:35:09AM +0100:
>>> Crazy thought: why not just implement conditionals? We had a
>>> proto-spec for them started at one point...
>>
>> I didn't
Excerpts from Alexis Lee's message of 2014-11-10 09:34:13 -0800:
> Zane Bitter said on Fri, Nov 07, 2014 at 12:35:09AM +0100:
> > Crazy thought: why not just implement conditionals? We had a
> > proto-spec for them started at one point...
>
> I didn't know that was on the table :)
>
> How about w
On 10/11/14 12:34, Alexis Lee wrote:
Zane Bitter said on Fri, Nov 07, 2014 at 12:35:09AM +0100:
Crazy thought: why not just implement conditionals? We had a
proto-spec for them started at one point...
I didn't know that was on the table :)
How about we support YAQL expressions? https://github
I like this approach and seems to have greater utility beyond the original
proposal. I'm not fussed on YAQL or straight up JSONPath, but something along
those lines seems to make sense.
On Nov 11, 2014, at 9:35 AM, Alexis Lee
wrote:
> Alexis Lee said on Mon, Nov 10, 2014 at 05:34:13PM +:
Alexis Lee said on Mon, Nov 10, 2014 at 05:34:13PM +:
> How about we support YAQL expressions? https://github.com/ativelkov/yaql
> Plus some HOFs (higher-order functions) like cond, map, filter, foldleft
> etc?
We could also use YAQL to provide the HOFs.
> Here's first_nonnull:
>
> config:
Zane Bitter said on Fri, Nov 07, 2014 at 12:35:09AM +0100:
> Crazy thought: why not just implement conditionals? We had a
> proto-spec for them started at one point...
I didn't know that was on the table :)
How about we support YAQL expressions? https://github.com/ativelkov/yaql
Plus some HOFs (h
23 matches
Mail list logo
