[openstack-dev] [Keystone] V3 Extensions Discoverability

Jamie Lennox jlennox at redhat.com
Tue Aug 6 23:25:16 UTC 2013


On Tue, 2013-08-06 at 11:17 -0400, Adam Young wrote:
> On 08/06/2013 10:54 AM, Dolph Mathews wrote:
> 
> > 
> > On Tue, Aug 6, 2013 at 9:28 AM, Jorge Williams
> > <jorge.williams at rackspace.com> wrote:
> >         
> >         On Aug 6, 2013, at 8:36 AM, Adam Young wrote:
> >         
> >         > On 08/06/2013 01:19 AM, Jamie Lennox wrote:
> >         >> Hi all,
> >         >>
> >         >> Partially in response to the trusts API review in
> >         keystoneclient
> >         >> (https://review.openstack.org/#/c/39899/ ) and my work on
> >         keystone API
> >         >> version discoverability (spell-check disagrees but I'm
> >         going to assume
> >         >> that's a word - https://review.openstack.org/#/c/38414/ )
> >         I was thinking
> >         >> about how we should be able to know what/if an extension
> >         is available. I
> >         >> even made a basic blueprint for how i think it should
> >         work:
> >         >>
> >         https://blueprints.launchpad.net/python-keystoneclient/+spec/keystoneclient-extensions and then realized that GET /extensions is only a V2 API.
> >         >
> >         > I'm not certain that the extensions should really be in
> >         the v2 or v3.  It always seemed to me that Extensions should
> >         be parallel to, and separate from, the core API.
> >         
> >         
> >         
> >         I agree. Extensions should not be in core, but the mechanism
> >         by which extensions are discovered should be part of the
> >         core...right?
> > 
> > 
> > Agree. The fact that you call GET /v2.0/extensions or
> > GET /v3/extensions instead of GET /extensions just means that we can
> > iterate on the "extensions" response itself, not necessarily that
> > the extension *only* applies to particular version API being queried
> > (that's a different issue).
> 
> Agreed.  That makes sense.
> 
> 
> So the APIs should be:
> 
> v2.0/extensions
> or
> v3/extensions
> 
> but those should return links to:
> 
> extensions/some_extension

This was my thoughts as well, there is no reason for the extension to be
versioned behind our keystone API because we don't expect the extension
api to change with the core api. Extension discoverability should be
behind our API because we reserve the right to change how extensions are
discovered. 

I think it also somewhat answers my question that we should be providing
a /v3/extensions rather than putting these into /v3/endpoints.

> >  
> >         
> >         -jOrGe W.
> >         
> >         
> >         _______________________________________________
> >         OpenStack-dev mailing list
> >         OpenStack-dev at lists.openstack.org
> >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >         
> > 
> > 
> > 
> > 
> > -- 
> > 
> > 
> > -Dolph 
> > 
> > 
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev






More information about the OpenStack-dev mailing list