<div dir="ltr"><div class="gmail_default" style="font-size:small">+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.</div><div class="gmail_default" style="font-size:small">
<br></div><div class="gmail_default" style="font-size:small">I'd like to point that there are at least two major flaws in the v1 design:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">
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.</div><div class="gmail_default" style="font-size:small">
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. </div>
<div class="gmail_default" style="font-size:small">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. </div>
<div class="gmail_default" style="font-size:small">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.</div>
<div class="gmail_default" style="font-size:small">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". </div>
<div class="gmail_default" style="font-size:small">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?</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">2. Currently our API acts like an interactive JSON editor: it allows to crated any arbitrary nested JSON structures.</div>
<div class="gmail_default" style="font-size:small">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. </div>
<div class="gmail_default" style="font-size:small">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. </div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So, this will require a significant modification of API, which means we have to design and deliver a v2 API spec. </div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><div><div dir="ltr"><font>--<br></font><div dir="ltr"><font>Regards,<br>
Alexander Tivelkov</font></div></div></div>
<br><br><div class="gmail_quote">On Mon, Jun 2, 2014 at 1:06 PM, Stan Lagun <span dir="ltr"><<a href="mailto:slagun@mirantis.com" target="_blank">slagun@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>I think API need to be redesigned at some point. There is a blueprint for this: <a href="https://blueprints.launchpad.net/murano/+spec/api-vnext" target="_blank">https://blueprints.launchpad.net/murano/+spec/api-vnext</a><br>
</div>It seems reasonable to implement new API on new framework at once<br></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small">Sincerely yours,<br>
Stan Lagun<br>Principal Software Engineer @ Mirantis</span></span><br><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small"><br>
<a href="mailto:slagun@mirantis.com" target="_blank"></a></span></span></div></div><div><div>
<br><br><div class="gmail_quote">On Mon, Jun 2, 2014 at 12:21 PM, Ruslan Kamaldinov <span dir="ltr"><<a href="mailto:rkamaldinov@mirantis.com" target="_blank">rkamaldinov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Let's follow the standard procedure. Both blueprints lack specification of<br>
implementation details. There also has to be someone willing to implement these<br>
blueprints in near feature.<br>
<br>
I'm not opposed to these ideas and I'd really like to see Pecan added during<br>
Juno, but we still need to follow the procedure. I cannot approve an idea, it<br>
should be a specification. Let's work together on the new API specification<br>
first, then we'll need to find a volunteer to implement it on top of Pecan.<br>
<br>
<br>
--<br>
Ruslan<br>
<div><div><br>
On Mon, Jun 2, 2014 at 8:35 AM, Timur Nurlygayanov<br>
<<a href="mailto:tnurlygayanov@mirantis.com" target="_blank">tnurlygayanov@mirantis.com</a>> wrote:<br>
> Hi all,<br>
><br>
> We need to rewrite Murano API on new API framework and we have the commit:<br>
> <a href="https://review.openstack.org/#/c/60787" target="_blank">https://review.openstack.org/#/c/60787</a><br>
> (Sergey, sorry, but -1 from me, need to fix small isses)<br>
><br>
> Also, today I created blueprint:<br>
> <a href="https://blueprints.launchpad.net/murano/+spec/murano-api-workers" target="_blank">https://blueprints.launchpad.net/murano/+spec/murano-api-workers</a><br>
> this feature allows to run many API threads on one host and this allows to<br>
> scale Murano API processes.<br>
><br>
> I suggest to update and merge this commit with migration to Pecan framework<br>
> and after that we can easily implement this blueprint and add many other<br>
> improvements to Murano API and Murano python agent.<br>
><br>
> Ruslan, could you please approve these blueprints and target them to some<br>
> milestone?<br>
><br>
><br>
> Thank you!<br>
><br>
> --<br>
><br>
> Timur,<br>
> QA Engineer<br>
> OpenStack Projects<br>
> Mirantis Inc<br>
><br>
</div></div>> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>