On Fri, 2013-11-22 at 20:07 -0600, Matt Riedemann wrote: > > On Friday, November 22, 2013 5:52:17 PM, Russell Bryant wrote: > > On 11/22/2013 06:01 PM, Christopher Yeoh wrote: > >> > >> On Sat, Nov 23, 2013 at 8:33 AM, Matt Riedemann > >> <mrie...@linux.vnet.ibm.com <mailto:mrie...@linux.vnet.ibm.com>> wrote: > >> > >> ... > >> 21:51:42 <dolphm> i just hope that the version discovery mechanism > >> is smart enough to realize when it's handed a versioned endpoint, > >> and happily run with that > >> ... > >> 21:52:00 <dolphm> (by calling that endpoint and doing proper > >> discovery) > >> ... > >> 21:52:24 <russellb> dolphm: yeah, need to handle that gracefully ... > >> > >> > >> > >> Just one point here (and perhaps I'm misunderstanding what was meant), > >> but if the catalog points to a versioned endpoint > >> shouldn't we just use that version rather than trying to discover what > >> other versions may be > >> available. Although we'll have cases of it just being set to a versioned > >> endpoint because thats how it > >> has been done in the past I think we should be making the assumption > >> that if we're pointed to a specific version, > >> that is the one we should be using. > > > > Agreed, and I think that's what Dolph and I meant. > > > > That also covers the override case that was expressed a few different > times in this thread, giving the admin the ability to pin his > environment to the version he knows and trusts during, for example, > upgrades, and then slowly transitioning to a newer API. The nice thing > with that approach is it should keep config options with hard-coded > versions out of nova.conf which is what was being proposed in the > glance and cinder v2 blueprint patches.
So the way we have this in keystone at least is that querying GET / will return all available API versions and querying /v2.0 for example is a similar result with just the v2 endpoint. So you can hard pin a version by using the versioned URL. I spoke to somebody the other day about the discovery process in services. The long term goal should be that the service catalog contains unversioned endpoints and that all clients should do discovery. For keystone the review has been underway for a while now: https://review.openstack.org/#/c/38414/ the basics of this should be able to be moved into OSLO for other projects if required. Jamie > -- > > Thanks, > > Matt Riedemann > > > _______________________________________________ > 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
