openstack team mailing list archive

[Devin Carlen <devin.carlen@xxxxxxxxx>]

Hey all,

I've been following the code vs architect debate that's been unfolding over the past week or so.  Here are some of the problems I've seen from my point of view.  Fundamentally, the process we have now for defining API specs is broken.  I don't believe that this can be argued.  The first major misstep in my opinion was forcing backwards compatibility with the Rackspace API in the OpenStack API.   

I believe we should have had a Rackspace API module just like we have an EC2 API module.  Then the OpenStack API wouldn't have been burdened by the historical decisions around the Rackspace API.

But that is ancient history at this point.

But we have to look at this pragmatically, and realize that 1 year later, the OpenStack API (as spec'd) is still not even close to exposing the underlying core functionality that exists within Nova.  For the most part, the OpenStack API is a subset of functionality of the EC2 API.   This is a big reason why the Dashboard project used the EC2 API for its underlying communication for so long.

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.

So the question to all in favor of architecting up front:

How do you explain lacking feature parity with the underlying components for over a year now? 


In my opinion, this has been a big problem in gaining traction around the OpenStack API.



Devin