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 :

> 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 
> 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  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  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
>>
>> 
>>
>> 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 
>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>> questions)" 
>>> 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

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

2016-06-27 Thread Alexey Khivin
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

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


Re: [openstack-dev] [murano] suggestion on commit message title format for the murano-apps repository

2015-09-30 Thread Alexey Khivin
lets discuss in more details how it should be

I have prepared a draft. please take a look
https://review.openstack.org/#/c/229477/




2015-09-25 13:16 GMT+03:00 Kirill Zaitsev :

> Looks reasonable to me! Could you maybe document that on HACKING.rst in
> the repo? We could vote on the commit itself.
>
> --
> Kirill Zaitsev
> Murano team
> Software Engineer
> Mirantis, Inc
>
> On 25 Sep 2015 at 02:14:09, Alexey Khivin (akhi...@mirantis.com) wrote:
>
> Hello everyone
>
> Almost an every commit-message in the murano-apps repository contains a
> name of the application which it is related to
>
> I suggest to specify application within commit message title using strict
> and uniform format
>
>
> For example, something like this:
>
> [ApacheHTTPServer] Utilize Custom Network selector
> <https://review.openstack.org/201659>
> [Docker/Kubernetes <https://review.openstack.org/208452>] Fix typo
> <https://review.openstack.org/208452>
>
> instead of this:
>
> Utilize Custom Network selector in Apache App
> Fix typo in Kubernetes Cluster app <https://review.openstack.org/208452>
>
>
> I think it would be useful for readability of the messages list
>
> --
> 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
>
>


-- 
Regards,
Alexey Khivin

Skype: khivin
+79169167297

+7 (495) 640-4904 (office)
+7 (495) 646-56-27 (fax)
Moscow, Russia, Vorontsovskaya St. 35B, bld.3
www.mirantis.ru ,www.mirantis.com
__
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-dev] [murano] suggestion on commit message title format for the murano-apps repository

2015-09-24 Thread Alexey Khivin
Hello everyone

Almost an every commit-message in the murano-apps repository contains a
name of the application which it is related to

I suggest to specify application within commit message title using strict
and uniform format


For example, something like this:

[ApacheHTTPServer] Utilize Custom Network selector
<https://review.openstack.org/201659>
[Docker/Kubernetes <https://review.openstack.org/208452>] Fix typo
<https://review.openstack.org/208452>

instead of this:

Utilize Custom Network selector in Apache App
Fix typo in Kubernetes Cluster app <https://review.openstack.org/208452>


I think it would be useful for readability of the messages list

-- 
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