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