Open Stack

On 5 July 2016 at 08:32, Renat Akhmerov <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

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 <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
>
> <slagun at mirantis.com>
>
> On Tue, Jun 28, 2016 at 9:46 AM, Elisha, Moshe (Nokia - IL) <
> 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
>>
>>
>>
>> From: Dougal Matthews <dougal at redhat.com>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> <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>
>> Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug
>>
>> On 27 June 2016 at 14:30, Alexey Khivin <akhivin at 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-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
>>>
>>>
>>
> __________________________________________________________________________
> 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
>
>
>
> __________________________________________________________________________
> 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/20160705/0560830f/attachment.html>