Open Stack

Great! Alex, enjoy using yaqluator :)

Renat Akhmerov
@Nokia

> On 05 Jul 2016, at 23:16, Elisha, Moshe (Nokia - IL) <moshe.elisha at 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 <dougal at redhat.com <mailto:dougal at redhat.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org>>
> Date: Tuesday, 5 July 2016 at 17:53
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org>>
> Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug
> 
> 
> 
> On 5 July 2016 at 08:32, Renat Akhmerov <renat.akhmerov at gmail.com <mailto:renat.akhmerov at 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 <slagun at mirantis.com <mailto:slagun at 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:slagun at mirantis.com>
>>> On Tue, Jun 28, 2016 at 9:46 AM, Elisha, Moshe (Nokia - IL) <moshe.elisha at nokia.com <mailto:moshe.elisha at 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 at 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 <dougal at redhat.com <mailto:dougal at redhat.com>>
>>>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org>>
>>>> Date: Monday, 27 June 2016 at 16:44
>>>> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org>>
>>>> Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug
>>>> 
>>>> On 27 June 2016 at 14:30, Alexey Khivin <akhivin at gmail.com <mailto:akhivin at 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-request at lists.openstack.org?subject:unsubscribe <http://OpenStack-dev-request@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-request at lists.openstack.org <mailto:OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> 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/20160706/539cbb38/attachment.html>