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.


OpenStack-dev mailing list

Reply via email to