Open Stack

On 09/23/2014 12:19 PM, Sean Dague wrote:
> On 09/23/2014 02:10 PM, Kevin L. Mitchell wrote:
>> On Tue, 2014-09-23 at 18:39 +0100, Louis Taylor wrote:
>>> On Tue, Sep 23, 2014 at 01:32:50PM -0400, Andrew Laski wrote:
>>>> I've been thinking along very similar lines, but I don't think each current
>>>> API needs to be replaced.  I would very much like to see a unified API
>>>> project that could be responsible for managing requests to "boot an instance
>>>> with this network and that volume" which would make requests to
>>>> Nova/Neutron/Cinder on the users behalf.
>>>
>>> Isn't this what openstacksdk [0] is?
>>>
>>> [0] https://wiki.openstack.org/wiki/SDK-Development/PythonOpenStackSDK
>>
>> Well, openstacksdk is a client, and we're talking about a server.  A
>> server, in this instance, has some advantages over a client, including
>> making it easier to create that client in the first place :)
>
> So today we have a proxy API in Nova which does some of this. I guess
> the question is is it better to do this in Nova in the future or divorce
> it from there.
>
> But regardless of approach, I don't think it really impacts whether or
> not we need to solve a saner versioning mechanism than we currently
> have... which is randomly add new extensions and pretend it's the same API.

I find the concept of "an" API version (i.e. a single version that 
applies to the whole API) to be not particularly useful.

Really what I care about is the API used to accomplish a specific task.

Why not do something like what is done for the userspace/kernel syscall 
API? Userspace code tries to use the most recent one it knows about, if 
that comes back as "not a valid syscall" then it tries the next older 
version.  As long as trying to use unsupported options fails cleanly, 
there is no ambiguity.

Realistically you'd want to have the complexity hidden behind a helper 
library, but this sort of thing would allow us to add new extensions 
without trying to enforce a version on the API as a whole.

Chris