openstack-poc team mailing list archive

[Bryan Taylor <btaylor@xxxxxxxxxxxxx>]

I think this is a very good proposal. I think making APIs explicitly
implementation neutral will help grow the OpenStack community, especially
by attracting vendors and operators who may want to put their own spin on
an alternative implementation. I'd like to see an ecosystem where multiple
API implementation teams can coexist and yet the rival teams collaborate
on the API itself.

I'm especially interested in this idea in conjunction with the OpenStack
Satellite concept that Chris Bohannon is discussing:
http://summit.openstack.org/sessions/view/3

On 9/23/11 12:26 PM, "Jay Pipes" <jaypipes@xxxxxxxxx> wrote:

>Hi PPB,
>
>So, recently, we've had discussions about who is responsible for a
>project's API and some discussions around coordination of APIs across
>OpenStack projects and general guidelines about APIs. All good stuff.
>
>However, I'd like to broach a subject that recently I've been thinking
>quite a bit about: separating the process of incubation of projects
>from the API over which that project aims to provide a service.
>
>Proposal
>====
>
>I propose that an API go through a separate life cycle than an
>implementation of an API
>
>This API life cycle would be:
>
>  1) Propose API for a resource to community (mailing list and PPB) (RFC)
>  2) Allow 3-4 weeks for community feedback
>  3) PPB votes on the proposed API in a weekly meeting, providing
>requests and feedback to the proposers where needed
>  4) PPB approves the proposed API
>  5) A {$resource}-api repository is created on GitHub/Gerrit and
>Anne's team works with the proposing team to pull their documentation
>of the proposed API into the standard API documentation format used by
>core projects currently
>  6) The API is published to docs.openstack.org
>
>Benefits:
>
>  1) This separates the API from the implementation of the API, which
>means:
>     a) People can write their projects in whatever programming
>language they choose -- The AMQP standard doesn't specify that a
>message queue server be implemented in Erlang or Python or whatever.
>OpenStack should be the same: if you write to the proposed and
>accepted API standard, why should it matter what programming language
>your service is written in?
>     b) OpenStack would actually fulfill its promise of Open
>Standards. Right now, we aren't. We are, instead, "Standards that
>Reflect the Current Core Python Project's Implementation". IMHO, to be
>successful as an open standards project we need to break out of that
>mindset
>  2) The FITS efforts can be broken down into a validation of the
>standard (the API) and a validation of expected
>performance/scalability/etc.
>  3) When a project "proposes for incubation", the PPB would be
>evaluating whether the project implements an approved OpenStack API
>for a resource. We would be able to use the FITS to determine
>eligibility of a project for incubation into core: if it passes the
>FITS for the API validation step, it would be eligible for incubation
>given open source code, demonstrated community input, good code
>quality, etc...
>
>I have a session at the design summit to discuss this very idea:
>
>http://summit.openstack.org/sessions/view/33
>
>Please do share your thoughts and I will ensure all your feedback is
>compiled into an Etherpad before that design summit session.
>
>Cheers!
>-jay

This email may include confidential information. If you received it in error, please delete it.