API definition process
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
- Milestone target:
- None
- Started by
- Vish Ishaya
- Completed by
- Vish Ishaya
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
