subject:"Re\: \[openstack\-dev\] \[mistral\] \[murano\] \[yaql\] yaqluator bug"

Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

2016-07-13 Thread Alexey Khivin

Thank You Renat, Moshe, Stan and all!


ср, 6 июл. 2016 г. в 7:01, Renat Akhmerov <renat.akhme...@gmail.com>:

> Great! Alex, enjoy using yaqluator :)
>
> Renat Akhmerov
> @Nokia
>
> On 05 Jul 2016, at 23:16, Elisha, Moshe (Nokia - IL) <
> moshe.eli...@nokia.com> wrote:
>
> Thank you all for assisting.
>
> When I tested Mistral I used an older version of Mistral (meaning an older
> version of yaql).
>
> I have verified that latest Mistral is working as expected.
> I have upgraded the yaql library in yaqluator to 1.1.0 and it is now
> working as expected.
>
> Thanks!
>
> From: Dougal Matthews <dou...@redhat.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Tuesday, 5 July 2016 at 17:53
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug
>
>
>
> On 5 July 2016 at 08:32, Renat Akhmerov <renat.akhme...@gmail.com> wrote:
>
>> Stan, thanks for clarification. What’s the latest stable version that
>> we’re supposed to use? global-requirements.txt has yaql>=1.1.0, I wonder
>> if it’s correct.
>>
>
> It is also worth looking at the upper-constraints.txt. It has 1.1.1 which
> is the latest release. So it all seems up to date.
>
>
> https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L376
>
> I think the problem is that this external project isn't being updated.
> Assuming they have not deployed anything that isn't committed, then they
> are running YAQL 1.0.2 which is almost a year old.
>
> https://github.com/ALU-CloudBand/yaqluator/blob/master/requirements.txt#L3
>
>
>>
>> Renat Akhmerov
>> @Nokia
>>
>> On 05 Jul 2016, at 12:12, Stan Lagun <sla...@mirantis.com> wrote:
>>
>> Hi!
>>
>> The issue with join is just a yaql bug that is already fixed. The problem
>> with yaqluator is that it doesn't use the latest yaql library.
>>
>> Another problem is that it does't sets options correctly. As a result it
>> is possible to bring the site down with a query that produces endless
>> collection
>>
>> Sincerely yours,
>> Stan Lagun
>> Principal Software Engineer @ Mirantis
>>
>> <sla...@mirantis.com>
>>
>> On Tue, Jun 28, 2016 at 9:46 AM, Elisha, Moshe (Nokia - IL) <
>> moshe.eli...@nokia.com> wrote:
>>
>>> Hi,
>>>
>>> Thank you for the kind words, Alexey.
>>>
>>> I was able to reproduce your bug and I have also found the issue.
>>>
>>> The problem is that we did not create the parser with the engine_options
>>> used in the yaql library by default when using the CLI.
>>> Specifically, the "yaql.limitIterators" was missing… I am not sure that
>>> this settings should have this affect but maybe the Yaql guys can comment
>>> on that.
>>>
>>> If we will change yaqluator to use this setting it will mean that
>>> yaqluator will not be consistent with Mistral because Mistral is using YAQL
>>> without this engine option (If I use your example in a workflow, Mistral
>>> returns exactly like the yaqluator returns)
>>>
>>>
>>> Workflow:
>>>
>>> ---
>>> version: '2.0'
>>>
>>> test_yaql:
>>>   tasks:
>>> test_yaql:
>>>   action: std.noop
>>>   publish:
>>> output_expr: <% [1,2].join([3], true, [$1, $2]) %>
>>>
>>>
>>> Workflow result:
>>>
>>>
>>> [root@s53-19 ~(keystone_admin)]# mistral task-get-published
>>> 01d2bce3-20d0-47b2-84f2-7bd1cb2bf9f7
>>> {
>>> "output_expr": [
>>> [
>>> 1,
>>> 3
>>> ]
>>> ]
>>> }
>>>
>>>
>>> As Matthews pointed out, the yaqluator is indeed OpenSource and
>>> contributions are welcomed.
>>>
>>> [1]
>>> https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2
>>>
>>>
>>>
>>> From: Dougal Matthews <dou...@redhat.com>
>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>> questions)" <openstack-dev@lists.openstack.org>
>>> Date: Monday, 27 June 2016 at 16:44
>>> To: "OpenStack Development Mailing List (not

Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

2016-07-05 Thread Renat Akhmerov

Great! Alex, enjoy using yaqluator :)

Renat Akhmerov
@Nokia

> On 05 Jul 2016, at 23:16, Elisha, Moshe (Nokia - IL) <moshe.eli...@nokia.com> 
> wrote:
> 
> Thank you all for assisting.
> 
> When I tested Mistral I used an older version of Mistral (meaning an older 
> version of yaql).
> 
> I have verified that latest Mistral is working as expected.
> I have upgraded the yaql library in yaqluator to 1.1.0 and it is now working 
> as expected.
> 
> Thanks!
> 
> From: Dougal Matthews <dou...@redhat.com <mailto:dou...@redhat.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org <mailto:openstack-dev@lists.openstack.org>>
> Date: Tuesday, 5 July 2016 at 17:53
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org <mailto:openstack-dev@lists.openstack.org>>
> Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug
> 
> 
> 
> On 5 July 2016 at 08:32, Renat Akhmerov <renat.akhme...@gmail.com 
> <mailto:renat.akhme...@gmail.com>> wrote:
>> Stan, thanks for clarification. What’s the latest stable version that we’re 
>> supposed to use? global-requirements.txt has yaql>=1.1.0,
>>  I wonder if it’s correct.
> 
> It is also worth looking at the upper-constraints.txt. It has 1.1.1 which is 
> the latest release. So it all seems up to date.
> 
> https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L376
>  
> <https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L376>
> 
> I think the problem is that this external project isn't being updated. 
> Assuming they have not deployed anything that isn't committed, then they are 
> running YAQL 1.0.2 which is almost a year old.
> 
> https://github.com/ALU-CloudBand/yaqluator/blob/master/requirements.txt#L3 
> <https://github.com/ALU-CloudBand/yaqluator/blob/master/requirements.txt#L3>
>  
>> 
>> Renat Akhmerov
>> @Nokia
>> 
>>> On 05 Jul 2016, at 12:12, Stan Lagun <sla...@mirantis.com 
>>> <mailto:sla...@mirantis.com>> wrote:
>>> 
>>> Hi!
>>> 
>>> The issue with join is just a yaql bug that is already fixed. The problem 
>>> with yaqluator is that it doesn't use the latest yaql library.
>>> 
>>> Another problem is that it does't sets options correctly. As a result it is 
>>> possible to bring the site down with a query that produces endless 
>>> collection
>>> 
>>> Sincerely yours,
>>> Stan Lagun
>>> Principal Software Engineer @ Mirantis
>>> 
>>>  <mailto:sla...@mirantis.com>
>>> On Tue, Jun 28, 2016 at 9:46 AM, Elisha, Moshe (Nokia - IL) 
>>> <moshe.eli...@nokia.com <mailto:moshe.eli...@nokia.com>> wrote:
>>>> Hi,
>>>> 
>>>> Thank you for the kind words, Alexey.
>>>> 
>>>> I was able to reproduce your bug and I have also found the issue.
>>>> 
>>>> The problem is that we did not create the parser with the engine_options 
>>>> used in the yaql library by default when using the CLI.
>>>> Specifically, the "yaql.limitIterators" was missing… I am not sure that 
>>>> this settings should have this affect but maybe the Yaql guys can comment 
>>>> on that.
>>>> 
>>>> If we will change yaqluator to use this setting it will mean that 
>>>> yaqluator will not be consistent with Mistral because Mistral is using 
>>>> YAQL without this engine option (If I use your example in a workflow, 
>>>> Mistral returns exactly like the yaqluator returns)
>>>> 
>>>> 
>>>> Workflow:
>>>> 
>>>>> ---
>>>>> version: '2.0'
>>>>> 
>>>>> test_yaql:
>>>>>   tasks:
>>>>> test_yaql:
>>>>>   action: std.noop
>>>>>   publish:
>>>>> output_expr: <% [1,2].join([3], true, [$1, $2]) %>
>>>> 
>>>> Workflow result:
>>>> 
>>>> 
>>>> [root@s53-19 ~(keystone_admin)]# mistral task-get-published 
>>>> 01d2bce3-20d0-47b2-84f2-7bd1cb2bf9f7
>>>> {
>>>> "output_expr": [
>>>> [
>>>> 1,
>>>> 3
>>>> ]
>>>> ]
>>>> }
>>>> 
>>>> 
>>>> As Matth

Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

2016-07-05 Thread Elisha, Moshe (Nokia - IL)

Thank you all for assisting.

When I tested Mistral I used an older version of Mistral (meaning an older 
version of yaql).

I have verified that latest Mistral is working as expected.
I have upgraded the yaql library in yaqluator to 1.1.0 and it is now working as 
expected.

Thanks!

From: Dougal Matthews <dou...@redhat.com<mailto:dou...@redhat.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, 5 July 2016 at 17:53
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug



On 5 July 2016 at 08:32, Renat Akhmerov 
<renat.akhme...@gmail.com<mailto:renat.akhme...@gmail.com>> wrote:
Stan, thanks for clarification. What’s the latest stable version that we’re 
supposed to use? global-requirements.txt has yaql>=1.1.0, I wonder if it’s 
correct.

It is also worth looking at the upper-constraints.txt. It has 1.1.1 which is 
the latest release. So it all seems up to date.

https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L376

I think the problem is that this external project isn't being updated. Assuming 
they have not deployed anything that isn't committed, then they are running 
YAQL 1.0.2 which is almost a year old.

https://github.com/ALU-CloudBand/yaqluator/blob/master/requirements.txt#L3


Renat Akhmerov
@Nokia

On 05 Jul 2016, at 12:12, Stan Lagun 
<sla...@mirantis.com<mailto:sla...@mirantis.com>> wrote:

Hi!

The issue with join is just a yaql bug that is already fixed. The problem with 
yaqluator is that it doesn't use the latest yaql library.

Another problem is that it does't sets options correctly. As a result it is 
possible to bring the site down with a query that produces endless collection

Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis

<mailto:sla...@mirantis.com>

On Tue, Jun 28, 2016 at 9:46 AM, Elisha, Moshe (Nokia - IL) 
<moshe.eli...@nokia.com<mailto:moshe.eli...@nokia.com>> wrote:
Hi,

Thank you for the kind words, Alexey.

I was able to reproduce your bug and I have also found the issue.

The problem is that we did not create the parser with the engine_options used 
in the yaql library by default when using the CLI.
Specifically, the "yaql.limitIterators" was missing… I am not sure that this 
settings should have this affect but maybe the Yaql guys can comment on that.

If we will change yaqluator to use this setting it will mean that yaqluator 
will not be consistent with Mistral because Mistral is using YAQL without this 
engine option (If I use your example in a workflow, Mistral returns exactly 
like the yaqluator returns)


Workflow:


---
version: '2.0'

test_yaql:
  tasks:
test_yaql:
  action: std.noop
  publish:
output_expr: <% [1,2].join([3], true, [$1, $2]) %>

Workflow result:


[root@s53-19 ~(keystone_admin)]# mistral task-get-published 
01d2bce3-20d0-47b2-84f2-7bd1cb2bf9f7
{
"output_expr": [
[
1,
3
]
]
}


As Matthews pointed out, the yaqluator is indeed OpenSource and contributions 
are welcomed.

[1] 
https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2



From: Dougal Matthews <dou...@redhat.com<mailto:dou...@redhat.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, 27 June 2016 at 16:44
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

On 27 June 2016 at 14:30, Alexey Khivin 
<akhi...@gmail.com<mailto:akhi...@gmail.com>> wrote:
Hello, Moshe

Tomorrow I discovered yaqluator.com<http://yaqluator.com/> for myself! Thanks 
for the useful tool!

But suddenly I was said that the expression
[1,2].join([3], true, [$1, $2])
evaluated to [[1,3]] on the yaqluator

A the same time this expression evaluated right when I using raw yaql 
interpreter.

Could we fix this issue?

By the way, don't you want to make yaqluator opensource? If you would transfer 
yaqluator to Openstack Foundation, then  community will be able to fix such 
kind of bugs

It looks like it is open source, there is a link in the footer: 
https://github.com/ALU-CloudBand/yaqluator


Thank you!
Best regards, Alexey Khivin



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe

Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

2016-07-05 Thread Dougal Matthews

On 5 July 2016 at 08:32, Renat Akhmerov <renat.akhme...@gmail.com> wrote:

> Stan, thanks for clarification. What’s the latest stable version that
> we’re supposed to use? global-requirements.txt has yaql>=1.1.0, I wonder
> if it’s correct.
>

It is also worth looking at the upper-constraints.txt. It has 1.1.1 which
is the latest release. So it all seems up to date.

https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L376

I think the problem is that this external project isn't being updated.
Assuming they have not deployed anything that isn't committed, then they
are running YAQL 1.0.2 which is almost a year old.

https://github.com/ALU-CloudBand/yaqluator/blob/master/requirements.txt#L3


>
> Renat Akhmerov
> @Nokia
>
> On 05 Jul 2016, at 12:12, Stan Lagun <sla...@mirantis.com> wrote:
>
> Hi!
>
> The issue with join is just a yaql bug that is already fixed. The problem
> with yaqluator is that it doesn't use the latest yaql library.
>
> Another problem is that it does't sets options correctly. As a result it
> is possible to bring the site down with a query that produces endless
> collection
>
> Sincerely yours,
> Stan Lagun
> Principal Software Engineer @ Mirantis
>
> <sla...@mirantis.com>
>
> On Tue, Jun 28, 2016 at 9:46 AM, Elisha, Moshe (Nokia - IL) <
> moshe.eli...@nokia.com> wrote:
>
>> Hi,
>>
>> Thank you for the kind words, Alexey.
>>
>> I was able to reproduce your bug and I have also found the issue.
>>
>> The problem is that we did not create the parser with the engine_options
>> used in the yaql library by default when using the CLI.
>> Specifically, the "yaql.limitIterators" was missing… I am not sure that
>> this settings should have this affect but maybe the Yaql guys can comment
>> on that.
>>
>> If we will change yaqluator to use this setting it will mean that
>> yaqluator will not be consistent with Mistral because Mistral is using YAQL
>> without this engine option (If I use your example in a workflow, Mistral
>> returns exactly like the yaqluator returns)
>>
>>
>> Workflow:
>>
>> ---
>> version: '2.0'
>>
>> test_yaql:
>>   tasks:
>> test_yaql:
>>   action: std.noop
>>   publish:
>> output_expr: <% [1,2].join([3], true, [$1, $2]) %>
>>
>>
>> Workflow result:
>>
>>
>> [root@s53-19 ~(keystone_admin)]# mistral task-get-published
>> 01d2bce3-20d0-47b2-84f2-7bd1cb2bf9f7
>> {
>> "output_expr": [
>> [
>> 1,
>> 3
>> ]
>> ]
>> }
>>
>>
>> As Matthews pointed out, the yaqluator is indeed OpenSource and
>> contributions are welcomed.
>>
>> [1]
>> https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2
>>
>>
>>
>> From: Dougal Matthews <dou...@redhat.com>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev@lists.openstack.org>
>> Date: Monday, 27 June 2016 at 16:44
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug
>>
>> On 27 June 2016 at 14:30, Alexey Khivin <akhi...@gmail.com> wrote:
>>
>>> Hello, Moshe
>>>
>>> Tomorrow I discovered yaqluator.com for myself! Thanks for the useful
>>> tool!
>>>
>>> But suddenly I was said that the expression
>>> [1,2].join([3], true, [$1, $2])
>>> evaluated to [[1,3]] on the yaqluator
>>>
>>> A the same time this expression evaluated right when I using raw yaql
>>> interpreter.
>>>
>>> Could we fix this issue?
>>>
>>> By the way, don't you want to make yaqluator opensource? If you would
>>> transfer yaqluator to Openstack Foundation, then  community will be able to
>>> fix such kind of bugs
>>>
>>
>> It looks like it is open source, there is a link in the footer:
>> https://github.com/ALU-CloudBand/yaqluator
>>
>>
>>>
>>> Thank you!
>>> Best regards, Alexey Khivin
>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> &l

Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

2016-07-05 Thread Renat Akhmerov

Stan, thanks for clarification. What’s the latest stable version that we’re 
supposed to use? global-requirements.txt has yaql>=1.1.0, I wonder if it’s 
correct.

Renat Akhmerov
@Nokia

> On 05 Jul 2016, at 12:12, Stan Lagun <sla...@mirantis.com> wrote:
> 
> Hi!
> 
> The issue with join is just a yaql bug that is already fixed. The problem 
> with yaqluator is that it doesn't use the latest yaql library.
> 
> Another problem is that it does't sets options correctly. As a result it is 
> possible to bring the site down with a query that produces endless collection
> 
> Sincerely yours,
> Stan Lagun
> Principal Software Engineer @ Mirantis
> 
>  <mailto:sla...@mirantis.com>
> On Tue, Jun 28, 2016 at 9:46 AM, Elisha, Moshe (Nokia - IL) 
> <moshe.eli...@nokia.com <mailto:moshe.eli...@nokia.com>> wrote:
> Hi,
> 
> Thank you for the kind words, Alexey.
> 
> I was able to reproduce your bug and I have also found the issue.
> 
> The problem is that we did not create the parser with the engine_options used 
> in the yaql library by default when using the CLI.
> Specifically, the "yaql.limitIterators" was missing… I am not sure that this 
> settings should have this affect but maybe the Yaql guys can comment on that.
> 
> If we will change yaqluator to use this setting it will mean that yaqluator 
> will not be consistent with Mistral because Mistral is using YAQL without 
> this engine option (If I use your example in a workflow, Mistral returns 
> exactly like the yaqluator returns)
> 
> 
> Workflow:
> 
> ---
> version: '2.0'
> 
> test_yaql:
>   tasks:
> test_yaql:
>   action: std.noop
>   publish:
> output_expr: <% [1,2].join([3], true, [$1, $2]) %>
> 
> Workflow result:
> 
> 
> [root@s53-19 ~(keystone_admin)]# mistral task-get-published 
> 01d2bce3-20d0-47b2-84f2-7bd1cb2bf9f7
> {
> "output_expr": [
> [
> 1,
> 3
> ]
> ]
> }
> 
> 
> As Matthews pointed out, the yaqluator is indeed OpenSource and contributions 
> are welcomed.
> 
> [1] 
> https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2
>  
> <https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2>
> 
> 
> 
> From: Dougal Matthews <dou...@redhat.com <mailto:dou...@redhat.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org <mailto:openstack-dev@lists.openstack.org>>
> Date: Monday, 27 June 2016 at 16:44
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org <mailto:openstack-dev@lists.openstack.org>>
> Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug
> 
> On 27 June 2016 at 14:30, Alexey Khivin <akhi...@gmail.com 
> <mailto:akhi...@gmail.com>> wrote:
> Hello, Moshe 
> 
> Tomorrow I discovered yaqluator.com <http://yaqluator.com/> for myself! 
> Thanks for the useful tool!
> 
> But suddenly I was said that the expression 
> [1,2].join([3], true, [$1, $2]) 
> evaluated to [[1,3]] on the yaqluator
> 
> A the same time this expression evaluated right when I using raw yaql 
> interpreter.
> 
> Could we fix this issue?
> 
> By the way, don't you want to make yaqluator opensource? If you would 
> transfer yaqluator to Openstack Foundation, then  community will be able to 
> fix such kind of bugs
> 
> It looks like it is open source, there is a link in the footer: 
> https://github.com/ALU-CloudBand/yaqluator 
> <https://github.com/ALU-CloudBand/yaqluator>
>  
> 
> Thank you!
> Best regards, Alexey Khivin
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

2016-07-04 Thread Stan Lagun

Hi!

The issue with join is just a yaql bug that is already fixed. The problem
with yaqluator is that it doesn't use the latest yaql library.

Another problem is that it does't sets options correctly. As a result it is
possible to bring the site down with a query that produces endless
collection

Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis

<sla...@mirantis.com>

On Tue, Jun 28, 2016 at 9:46 AM, Elisha, Moshe (Nokia - IL) <
moshe.eli...@nokia.com> wrote:

> Hi,
>
> Thank you for the kind words, Alexey.
>
> I was able to reproduce your bug and I have also found the issue.
>
> The problem is that we did not create the parser with the engine_options
> used in the yaql library by default when using the CLI.
> Specifically, the "yaql.limitIterators" was missing… I am not sure that
> this settings should have this affect but maybe the Yaql guys can comment
> on that.
>
> If we will change yaqluator to use this setting it will mean that
> yaqluator will not be consistent with Mistral because Mistral is using YAQL
> without this engine option (If I use your example in a workflow, Mistral
> returns exactly like the yaqluator returns)
>
>
> Workflow:
>
> ---
> version: '2.0'
>
> test_yaql:
>   tasks:
> test_yaql:
>   action: std.noop
>   publish:
> output_expr: <% [1,2].join([3], true, [$1, $2]) %>
>
>
> Workflow result:
>
>
> [root@s53-19 ~(keystone_admin)]# mistral task-get-published
> 01d2bce3-20d0-47b2-84f2-7bd1cb2bf9f7
> {
> "output_expr": [
> [
> 1,
> 3
> ]
> ]
> }
>
>
> As Matthews pointed out, the yaqluator is indeed OpenSource and
> contributions are welcomed.
>
> [1]
> https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2
>
>
>
> From: Dougal Matthews <dou...@redhat.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Monday, 27 June 2016 at 16:44
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug
>
> On 27 June 2016 at 14:30, Alexey Khivin <akhi...@gmail.com> wrote:
>
>> Hello, Moshe
>>
>> Tomorrow I discovered yaqluator.com for myself! Thanks for the useful
>> tool!
>>
>> But suddenly I was said that the expression
>> [1,2].join([3], true, [$1, $2])
>> evaluated to [[1,3]] on the yaqluator
>>
>> A the same time this expression evaluated right when I using raw yaql
>> interpreter.
>>
>> Could we fix this issue?
>>
>> By the way, don't you want to make yaqluator opensource? If you would
>> transfer yaqluator to Openstack Foundation, then  community will be able to
>> fix such kind of bugs
>>
>
> It looks like it is open source, there is a link in the footer:
> https://github.com/ALU-CloudBand/yaqluator
>
>
>>
>> Thank you!
>> Best regards, Alexey Khivin
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

2016-07-04 Thread Renat Akhmerov

If I understand the meaning of “join” function correctly then from user 
perspective this behavior in Mistral and Yaqluator is a bug because we’re 
joining two collections similar to how it works in SQL so the correct result 
should be:

[[1, 3], [2, 3]]

I.e. collection consisting of two collections where each element if the first 
one is combined with each element of the second one.

If so, we need to fix this in both Mistral and Yaqluator.


Alex, Stan, do you agree?

Renat Akhmerov
@Nokia

> On 28 Jun 2016, at 23:46, Elisha, Moshe (Nokia - IL) <moshe.eli...@nokia.com> 
> wrote:
> 
> Hi,
> 
> Thank you for the kind words, Alexey.
> 
> I was able to reproduce your bug and I have also found the issue.
> 
> The problem is that we did not create the parser with the engine_options used 
> in the yaql library by default when using the CLI.
> Specifically, the "yaql.limitIterators" was missing… I am not sure that this 
> settings should have this affect but maybe the Yaql guys can comment on that.
> 
> If we will change yaqluator to use this setting it will mean that yaqluator 
> will not be consistent with Mistral because Mistral is using YAQL without 
> this engine option (If I use your example in a workflow, Mistral returns 
> exactly like the yaqluator returns)
> 
> 
> Workflow:
> 
>> ---
>> version: '2.0'
>> 
>> test_yaql:
>>   tasks:
>> test_yaql:
>>   action: std.noop
>>   publish:
>> output_expr: <% [1,2].join([3], true, [$1, $2]) %>
> 
> Workflow result:
> 
> 
> [root@s53-19 ~(keystone_admin)]# mistral task-get-published 
> 01d2bce3-20d0-47b2-84f2-7bd1cb2bf9f7
> {
> "output_expr": [
> [
> 1,
> 3
> ]
> ]
> }
> 
> 
> As Matthews pointed out, the yaqluator is indeed OpenSource and contributions 
> are welcomed.
> 
> [1] 
> https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2
>  
> <https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2>
> 
> 
> 
> From: Dougal Matthews <dou...@redhat.com <mailto:dou...@redhat.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org <mailto:openstack-dev@lists.openstack.org>>
> Date: Monday, 27 June 2016 at 16:44
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org <mailto:openstack-dev@lists.openstack.org>>
> Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug
> 
> On 27 June 2016 at 14:30, Alexey Khivin <akhi...@gmail.com 
> <mailto:akhi...@gmail.com>> wrote:
>> Hello, Moshe 
>> 
>> Tomorrow I discovered yaqluator.com <http://yaqluator.com/> for myself! 
>> Thanks for the useful tool!
>> 
>> But suddenly I was said that the expression 
>> [1,2].join([3], true, [$1, $2]) 
>> evaluated to [[1,3]] on the yaqluator
>> 
>> A the same time this expression evaluated right when I using raw yaql 
>> interpreter.
>> 
>> Could we fix this issue?
>> 
>> By the way, don't you want to make yaqluator opensource? If you would 
>> transfer yaqluator to Openstack Foundation, then  community will be able to 
>> fix such kind of bugs
> 
> It looks like it is open source, there is a link in the footer: 
> https://github.com/ALU-CloudBand/yaqluator 
> <https://github.com/ALU-CloudBand/yaqluator>
>  
>> 
>> Thank you!
>> Best regards, Alexey Khivin
>> 
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

2016-06-28 Thread Elisha, Moshe (Nokia - IL)

Hi,

Thank you for the kind words, Alexey.

I was able to reproduce your bug and I have also found the issue.

The problem is that we did not create the parser with the engine_options used 
in the yaql library by default when using the CLI.
Specifically, the "yaql.limitIterators" was missing… I am not sure that this 
settings should have this affect but maybe the Yaql guys can comment on that.

If we will change yaqluator to use this setting it will mean that yaqluator 
will not be consistent with Mistral because Mistral is using YAQL without this 
engine option (If I use your example in a workflow, Mistral returns exactly 
like the yaqluator returns)


Workflow:


---
version: '2.0'

test_yaql:
  tasks:
test_yaql:
  action: std.noop
  publish:
output_expr: <% [1,2].join([3], true, [$1, $2]) %>

Workflow result:


[root@s53-19 ~(keystone_admin)]# mistral task-get-published 
01d2bce3-20d0-47b2-84f2-7bd1cb2bf9f7
{
"output_expr": [
[
1,
3
]
]
}


As Matthews pointed out, the yaqluator is indeed OpenSource and contributions 
are welcomed.

[1] 
https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2



From: Dougal Matthews <dou...@redhat.com<mailto:dou...@redhat.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, 27 June 2016 at 16:44
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

On 27 June 2016 at 14:30, Alexey Khivin 
<akhi...@gmail.com<mailto:akhi...@gmail.com>> wrote:
Hello, Moshe

Tomorrow I discovered yaqluator.com<http://yaqluator.com> for myself! Thanks 
for the useful tool!

But suddenly I was said that the expression
[1,2].join([3], true, [$1, $2])
evaluated to [[1,3]] on the yaqluator

A the same time this expression evaluated right when I using raw yaql 
interpreter.

Could we fix this issue?

By the way, don't you want to make yaqluator opensource? If you would transfer 
yaqluator to Openstack Foundation, then  community will be able to fix such 
kind of bugs

It looks like it is open source, there is a link in the footer: 
https://github.com/ALU-CloudBand/yaqluator


Thank you!
Best regards, Alexey Khivin



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

2016-06-27 Thread Dougal Matthews

On 27 June 2016 at 14:30, Alexey Khivin  wrote:

> Hello, Moshe
>
> Tomorrow I discovered yaqluator.com for myself! Thanks for the useful
> tool!
>
> But suddenly I was said that the expression
> [1,2].join([3], true, [$1, $2])
> evaluated to [[1,3]] on the yaqluator
>
> A the same time this expression evaluated right when I using raw yaql
> interpreter.
>
> Could we fix this issue?
>
> By the way, don't you want to make yaqluator opensource? If you would
> transfer yaqluator to Openstack Foundation, then  community will be able to
> fix such kind of bugs
>

It looks like it is open source, there is a link in the footer:
https://github.com/ALU-CloudBand/yaqluator


>
> Thank you!
> Best regards, Alexey Khivin
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug

9 matches

Site Navigation

Mail list logo

Footer information