[occi-wg] Fwd: [Openstack] 3rd Party APIs

[Alan Sill]

FYI - please feel free to join the Openstack list (and the openstack-dev list if that gets going) and contribute your knowledge and implementations as suggested and requested below.

Alan

Begin forwarded message:

> From: Mark McLoughlin <markmc at redhat.com>
> Subject: Re: [Openstack] 3rd Party APIs
> Date: May 8, 2012 9:58:45 AM CDT
> To: "openstack at lists.launchpad.net" <openstack at lists.launchpad.net>
> Cc: "openstack-poc at lists.launchpad.net" <openstack-poc at lists.launchpad.net>
> Reply-To: Mark McLoughlin <markmc at redhat.com>
> 
> Hey,
> 
> I just realised there's a thread on the openstack-poc list about how
> OpenStack should view implementations of APIs other than the OpenStack
> API:
> 
>  https://lists.launchpad.net/openstack-poc/msg00448.html
> 
> (PPB members - please note that other folks can't subscribe to the POC
> list. If you want an open discussion on something, the openstack-poc
> list isn't the place for it)
> 
> 
> tl;dr - rather than actively discouraging folks from contributing native
> API implementations, encourage them to resolve the current difficulties
> with the EC2 API and their work as a test case for feature/subsystem
> branch development process.
> 
> 
> The discussion is fairly complex and seems to degenerate into an overly
> general "what is and is not core" discussion. There also seems to be a
> sense of urgency around finding a final solution here, which I don't
> fully understand. The truth is we don't know the answer. We just need to
> have some rough idea of what we're trying to achieve and figure out the
> thing we want to try next. We'll likely have to try a bunch of stuff
> before finding one that works.
> 
> What I'd like to see us get to is:
> 
>  Deep overlap between the OpenStack developer community and the
>  community of folks drafting whatever IaaS standard(s) wind up being
>  dominant.
> 
>  e.g. prominent, active Nova developers developers contributing to the 
>  CIMI or OCCI standards and bringing the needs of OpenStack to the 
>  standard and bringing ideas from the standards process to OpenStack.
> 
> This isn't a question of asking existing OpenStack developers to join
> these standards bodies. It's about enabling members of those standards
> bodies to become as much a part of OpenStack as any other developer.
> 
> How to do that? Encourage members the various standards communities to
> actively contribute an implementation of their standard to OpenStack
> and, more importantly, stick around to become an ongoing active member
> of the OpenStack developer community.
> 
> If this worked out, OpenStack would gain new developers, new ideas and
> would be seen as the best place to do new work around IaaS APIs.
> 
> 
> AFAICT nova-core has two major concerns with the EC2 API - 1) currently
> having to make a change once in the OpenStack API and again in the EC2
> API and 2) the EC2 isn't maintenance isn't sufficiently active.
> 
> I think a lot of the urgency around this discussion is wanting to avoid
> exacerbating the situation by adding another API. To me, the answer is
> fairly simple. We cannot accept a new API until these concerns are
> addressed:
> 
>  1) The amount of duplication between the OpenStack, EC2 and any 
>     proposed API needs to be significantly reduced
> 
>  2) The developers of any proposed new API need to demonstrate a 
>     commitment (through their work) to sticking around as active 
>     OpenStack developers maintaining the API (perhaps as a subsystem 
>     tree)
> 
> That's a high bar, and I expect only seriously committed contributors
> would meet it. In the meantime, those contributors can work on their
> APIs as feature branches and encourage others to give feedback.
> 
> 
> Two alternatives to the above are on the table. Firstly, implementing
> these APIs as deltacloud-like proxy servers and blessing these as
> "official" OpenStack products. IMHO, proxies are architecturally less
> than ideal. Perhaps with enough engineering effort (including OpenStack
> API additions) we can get to where they are almost on-par with a native
> API, but I'm sceptical.
> 
> The other option is to support these APIs with external plugins. For us
> to get there, we need a stable library-like API that these plugins can
> depend on. It's potentially an ideal solution, but I think we've a long
> way to get there. A stepping stone is the re-factoring to reduce
> duplication between APIs.
> 
> 
> Cheers,
> Mark.
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp