(and thus port YAQL to JS) FYI, you’re not the first one to have that idea. =)
We have https://review.openstack.org/#/c/159905/3 an initial draft of how YAQL may look on JS. It’s outdated, but most certainly can be revived and finished if you have interest in helping us make it happen. =) -- Kirill Zaitsev Murano team Software Engineer Mirantis, Inc On 2 March 2016 at 14:01:57, Vitaly Kramskikh (vkramsk...@mirantis.com) wrote: Oh, so there is a spec. I was worried that this patch has "WIP-no-bprint-assigned-yet" string in the commit message, so I thought there is no spec for it. So the commit message should be updated to avoid such confusion. It's really good I've seen this spec. There are plans to overhaul UI data format description which we use for cluster and node settings to solve some issues and implement long-awaited features like nested structures, so we might also want to deprecate our expression language and also switch to YAQL (and thus port YAQL to JS). 2016-03-02 17:17 GMT+07:00 Vladimir Kuklin <vkuk...@mirantis.com>: Vitaly Thanks for bringing this up. Actually the spec has been on review for almost 2 weeks: https://review.openstack.org/#/c/282695/. Essentially, this is not introducing new DSL but replacing the existing one with more powerful extendable language which is being actively developed within OpenStack and is already a part of other projects (Murano, Mistral), which has much more contributors, can return not only boolean but any arbitrary collections. So it means that we want to deprecate current Expression language that you wrote and replace it with YAQL due to those reasons. You are not going to extend this Expression-based language in 3 weeks up to level of support of extensions, method overloading, return of arbitrary collections (e.g. we also want to calculate cross-depends and requires fields on the fly which require for it to return list of dicts) and support of this stuff on your own, are you? On Wed, Mar 2, 2016 at 10:09 AM, Vitaly Kramskikh <vkramsk...@mirantis.com> wrote: I think it's not a part of best practices to introduce changes like https://review.openstack.org/#/c/279714/ (adding yet another DSL to the project) without a blueprint and review and discussion of the spec. 2016-03-02 2:19 GMT+07:00 Alexey Shtokolov <ashtoko...@mirantis.com>: Fuelers, I would like to request a feature freeze exception for "Unlock settings tab" feature [0] This feature being combined with Task-based deployment [1] and LCM-readiness for Fuel deployment tasks [2] unlocks Basic LCM in Fuel. We conducted a thorough redesign of this feature and splitted it into several granular changes [3]-[6] to allow users to change settings on deployed, partially deployed, stopped or erred clusters and further run redeployment using a particular graph (custom or calculated based on expected changes stored in DB) and with new parameters. We need 3 weeks after FF to finish this feature. Risk of not delivering it after 3 weeks is low. Patches on review or in progress: https://review.openstack.org/#/c/284139/ https://review.openstack.org/#/c/279714/ https://review.openstack.org/#/c/286754/ https://review.openstack.org/#/c/286783/ Specs: https://review.openstack.org/#/c/286713/ https://review.openstack.org/#/c/284797/ https://review.openstack.org/#/c/282695/ https://review.openstack.org/#/c/284250/ [0] https://blueprints.launchpad.net/fuel/+spec/unlock-settings-tab [1] https://blueprints.launchpad.net/fuel/+spec/enable-task-based-deployment [2] https://blueprints.launchpad.net/fuel/+spec/granular-task-lcm-readiness [3] https://blueprints.launchpad.net/fuel/+spec/computable-task-fields-yaql [4] https://blueprints.launchpad.net/fuel/+spec/store-deployment-tasks-history [5] https://blueprints.launchpad.net/fuel/+spec/custom-graph-execution [6] https://blueprints.launchpad.net/fuel/+spec/save-deployment-info-in-database -- --- WBR, Alexey Shtokolov __________________________________________________________________________ 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 -- Vitaly Kramskikh, Fuel UI Tech Lead, Mirantis, Inc. __________________________________________________________________________ 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 -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com www.mirantis.ru vkuk...@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 -- Vitaly Kramskikh, Fuel UI Tech Lead, Mirantis, Inc. __________________________________________________________________________ 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
