[openstack-dev] [Murano] Murano API improvements

Alexander Tivelkov ativelkov at mirantis.com
Wed Jun 4 09:59:17 UTC 2014


+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 <slagun at 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
>
>  <slagun at mirantis.com>
>
>
> On Mon, Jun 2, 2014 at 12:21 PM, Ruslan Kamaldinov <
> rkamaldinov at 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
>> <tnurlygayanov at 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 at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20140604/39bb0820/attachment.html>


More information about the OpenStack-dev mailing list