...@fewbar.com
To: openstack-dev openstack-dev@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
On Thu, Nov 13, 2014 at 4:00 AM, Clint Byrum cl...@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
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
On Wed, Nov 12, 2014 at 9:33 PM, Alexis Lee alex...@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
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
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 Wed, Nov 12, 2014 at 3:50 PM, Zane Bitter 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.
Could you please give an example of template with
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 embed
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,
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
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
On Nov 12, 2014, at 10:42 AM, Zane Bitter zbit...@redhat.com
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
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
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 alex...@hp.com
wrote:
Alexis Lee said on Mon, Nov 10, 2014 at
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?
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 we
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 know that
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
On Wed, Nov 12, 2014 at 1:35 AM, Alexis Lee alex...@hp.com 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
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
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
21 matches
Mail list logo
