[openstack-tc] Proposal for API version discovery

Dolph Mathews dolph.mathews at gmail.com
Thu May 2 04:12:01 UTC 2013


On Wed, May 1, 2013 at 10:50 PM, John Griffith
<john.griffith at solidfire.com>wrote:

>
>
>
> On Wed, May 1, 2013 at 6:58 PM, Monty Taylor <mordred at inaugust.com> wrote:
>
>>
>>
>> On 05/01/2013 08:46 PM, Gabriel Hurley wrote:
>> > Based on input from several of the PTLs (and others), I'd like to
>> > propose the following outline for how version discovery should be
>> > handled across heterogeneous clouds:
>> >
>> > https://etherpad.openstack.org/api-version-discovery-proposal
>> >
>> > Further discussion is absolutely welcome, and I would like to propose
>> > it as a topic for review by the Technical Committee at the next
>> > meeting since it involves a significant cross-project standardization
>> > effort.
>>
>> I dirtied your pretty doc with two questions - but they are nitpicky
>> things. In general, I think it's sexy.
>>
>>
>> _______________________________________________
>> OpenStack-TC mailing list
>> OpenStack-TC at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc
>>
>
> Hi Gabriel,
>
> Wondering if you'd mind describing a bit more the problem you're actually
> trying to solve here?  I don't quite understand what you see as the actual
> use case, and in particular the extensions piece.
>
>
Given that every deployment has versioned endpoints in their service
catalogs, how would you go about adding an additional API version to the
catalog (or when is it safe to update the service catalog with a new API
version?)

Instead, put unversioned endpoints in the catalog and allow the services to
advertise whatever they support; but first, we need intelligent clients
that can work out their own preferences (which can also support catalogs
with versioned endpoints).

That being said, I'm all about the discovery piece and think it's  a great
> idea, however I'd like to know how far this goes.  Is it just "I offer
> x,y,z versions of the API"?
>

... and "as a client I understand API versions 'y' and 'z', but while your
'z' implementation is 'beta', my 'z' implementation is stable... so I'll
work with 'y'. I also see that you support extensions A and B, but not C,
so I'll hide C-related features from the user."


>
> I am confused as to how this addresses things like multiple drivers in an
> environment such as Cinder or Nova where that sort of thing is typically
> abstracted out.  How does this look from a tenant perspective?  Sorry,
> these are some of the questions I brought up yesterday, I'd be curious to
> hear more.
>
> Thanks,
> John
>
> _______________________________________________
> OpenStack-TC mailing list
> OpenStack-TC at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20130501/b9b5e202/attachment-0001.html>


More information about the OpenStack-TC mailing list