openstack-poc team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

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