API definition process

Registered by Soren Hansen on 2011-03-15

We need to discuss and possibly revise the way we define the OpenStack API. It's currently being defined by people other than the ones implementing it, and it's being defined as a massive, single feature. It seems like a much more natural approach to have an "Changes to the API" section for each proposed feature spec and have it be defined in that context.

I propose we have this discussion at the upcoming summit as one of the very first sessions as it will have an impact on all the rest.

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
Soren Hansen
Direction:
Needs approval
Assignee:
None
Definition:
Approved
Series goal:
None
Implementation:
Informational Informational
Milestone target:
None
Started by
Vish Ishaya on 2011-05-06
Completed by
Vish Ishaya on 2011-05-06

Related branches

Sprints

Whiteboard

justinsb wrote:

I totally agree that our API process needs reconsideration. My preferred approach would be to define a native OpenStack API that is of our own design, and legacy-free. Then EC2 and CloudServers v1.0 and v1.1 could simply be proxies to the native API. These proxies will likely be stateful and full-fledged services in their own right. For example, if Rackspace wants to allow clients to continue to use the CloudServers bindings, they have to use 32 bit signed integers for their IDs, but OpenStack will likely move to use strings in future. The CloudServer API proxy would therefore need to track mappings of integer IDs to string IDs, presumably in a database (of some kind). The big advantage here is organizational: Rackspace can take full ownership of their API and do whatever they want with it; the OpenStack community can develop an API that meets our needs without worrying about backwards compatibility, and in future when other providers decide to use OpenStack they can simply write their own proxies for their legacy API customers. We should be mindful of how those proxies will work, but we shouldn't be bound by APIs that were not designed with our ambitions in mind (as long as it is practical for someone to write a translation proxy.) I agree this should be one of the first discussions, it will likely have a huge impact on other discussions if e.g. we don't have to worry about squashing IDs into 32 bits.

Discussed at the summit. There isn't a specific code change required for this so changing implementation to informational

(?)

Work Items