OpenStack Essex Design Summit

This session is a discussion session that discusses why the OpenStack community and governance boards should consider the API separately from the implementation of the API. The API and the implementation should be separated entirely, including having the PPB (or some other focused group) vote *separately* on the API of a layer separately from the implementation of that layer. This would make it much easier for competing implementations to be written and blessed" as OpenStack compliant. The Object Storage API ould then have non-Python implementations, such as what has been done by the folks at GlusterFS and is being worked on for two other storage systems/vendors. Likewise, if Rackspace IT or some other organization (just using Rackspace IT as an example since I recently spoke with them.. ;) ) have a Java implementation of the Images API, they could go ahead and use that without worrying that their implementation would break other parts of OpenStack. In addition, these folks could propose their implementation for inclusion into "core Openstack". That said, if you separate out the API from the implementation, the idea of "core OpenStack" might be able to change from "a set of mostly Python projects (because that's what things were implemented in...)" to "a set of projects that implement the core OpenStack APIs". Another way to think of it: We don't say that RabbitMQ is "core AMQP". We say that RabbitMQ "implements the AMQP standard". OpenStack should be similar: a standard set of APIs for cloud components, with a set of implementations of those APIs.