Open Stack

(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 (vkramskikh at 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 <vkuklin at 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 <vkramskikh at 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 <ashtokolov at 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-request at 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-request at 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
vkuklin at mirantis.com

__________________________________________________________________________
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




--
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__________________________________________________________________________  
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/20160304/ff4196bd/attachment-0001.html>