Open Stack

On 8/26/11 1:19 PM, "Devin Carlen" <devin.carlen at gmail.com> wrote:

>There have been a lot of efforts lately to bring the feature set of the
>OpenStack API in line with the EC2 API, and this is admirable.  But this
>has NOT been happening at the architect level.  This has been happening
>at the developer level, and it is being done with API "extensions" which
>make it sound like the feature is somehow not complete or not supported
>fully, because it's not part of the core API.

I think you are hitting on a perception problem around extensions that
might be solvable by taking some steps to make the intent clear. I propose
two things: always keep the next version of the API in play and improve
the classification of the extensions.

Developers have to choose to contribute in a way that either works with
the current APIs or not. Mixing these is bad, and fortunately unnecessary.
The two tracks should probably have different tech leads.

How about this as classification system for extensions:

temporary extension ­ accepted for addition to core api in the next
backwards compatible version uprev
backport extension ‹ accepted for addition to core api in the next
non-backwards compatible version uprev
default extension  ­ viewed as standard, but not incorporated into the
core to allow opt-out by an operator
common extension ‹  viewed as the preferred solution, but must be an
opt-in by an operator
candidate extension ‹ an extension viewed as trying to prove itself worthy
for a higher level
private extension ‹ an extension not offered or not accepted for a higher
level

Thoughts?

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