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.willi...@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@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > > > -- > > > > > > -Dolph > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev