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 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 >>> <mailto: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://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
