+2 to Stan: there is a strong need for v2 API which would satisfy the needs of Murano 0.5+. The current one is definitely outdated.
I'd like to point that there are at least two major flaws in the v1 design: 1. Sessions. Actually, they violate one of the core principles of RESTful design - the client's state should not be stored on server, while our session implicitly do so. I would suggest to drop client-bound sessions entirely and instead introduce a concept of "environment modification drafts": each environment may have an associated "draft" containing changes which are currently pending. These changes may include new components which have to be added to environment or modified copies of already existing components which have to be changed. There should be just one "draft" per environment, and any user of the tenant may see it, interact with it, "apply" it (i.e. run the deployment) etc. When the deployment is started, the "draft" is blocked (i.e. nobody can plan any other changes), and when it finishes the "new" configuration is saved within the environment, and the "draft" is cleaned up. In UI this may be implemented as having two tables for "components view" of the environment, where one of the table contains "current state" of the environment, while the second lists the "Pending changes". This is just s brief suggestions on this topic, if there are other opinions, please post them here. Or should we create an etherpad to discuss it more actively? 2. Currently our API acts like an interactive JSON editor: it allows to crated any arbitrary nested JSON structures. Instead, it should act as an interactive editor of the valid Murano object model, and the API itself should be aware of Murano's specific: i.e. it should be able to differentiate between nesting objects and setting a link to the object existing at other model location, validate contracts etc. Also there was an idea of introducing a "MuranoPL wizards to init the object model". This worths a separate email, but, briefly speaking, there should be a way to define some MuranoPL code which will construct a complex Murano object model based on the simple input, and this code has to be executed at API side. This will also require significant modifications of the API and making it aware of available MuranoPL "wizard initializers" and their semantics. So, this will require a significant modification of API, which means we have to design and deliver a v2 API spec. -- Regards, Alexander Tivelkov On Mon, Jun 2, 2014 at 1:06 PM, Stan Lagun <sla...@mirantis.com> wrote: > I think API need to be redesigned at some point. There is a blueprint for > this: https://blueprints.launchpad.net/murano/+spec/api-vnext > It seems reasonable to implement new API on new framework at once > > Sincerely yours, > Stan Lagun > Principal Software Engineer @ Mirantis > > <sla...@mirantis.com> > > > On Mon, Jun 2, 2014 at 12:21 PM, Ruslan Kamaldinov < > rkamaldi...@mirantis.com> wrote: > >> Let's follow the standard procedure. Both blueprints lack specification of >> implementation details. There also has to be someone willing to implement >> these >> blueprints in near feature. >> >> I'm not opposed to these ideas and I'd really like to see Pecan added >> during >> Juno, but we still need to follow the procedure. I cannot approve an >> idea, it >> should be a specification. Let's work together on the new API >> specification >> first, then we'll need to find a volunteer to implement it on top of >> Pecan. >> >> >> -- >> Ruslan >> >> On Mon, Jun 2, 2014 at 8:35 AM, Timur Nurlygayanov >> <tnurlygaya...@mirantis.com> wrote: >> > Hi all, >> > >> > We need to rewrite Murano API on new API framework and we have the >> commit: >> > https://review.openstack.org/#/c/60787 >> > (Sergey, sorry, but -1 from me, need to fix small isses) >> > >> > Also, today I created blueprint: >> > https://blueprints.launchpad.net/murano/+spec/murano-api-workers >> > this feature allows to run many API threads on one host and this allows >> to >> > scale Murano API processes. >> > >> > I suggest to update and merge this commit with migration to Pecan >> framework >> > and after that we can easily implement this blueprint and add many other >> > improvements to Murano API and Murano python agent. >> > >> > Ruslan, could you please approve these blueprints and target them to >> some >> > milestone? >> > >> > >> > Thank you! >> > >> > -- >> > >> > Timur, >> > QA Engineer >> > OpenStack Projects >> > Mirantis Inc >> > >> > _______________________________________________ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
