On Tue, Feb 16, 2016 at 1:04 PM, Dean Troyer <dtro...@gmail.com> wrote:
> > > On Tue, Feb 16, 2016 at 12:17 PM, Sean Dague <s...@dague.net> wrote: > >> Honestly, doing per API call version switching is probably going to end >> in tears. HTTP is stateless, so it's allowed, but it will end in tears >> of complexity as you need to self modify resources before passing them >> back. Or follow links that don't exist. >> > > Maybe. But any code that knows it is using a specific version already is > handling the special cases. We are trading the speed of implementation for > the juggling of multiple versions, no matter if they are labelled > sequentially or via semver. I've seen places that mixed Identity v2 and v3 > because of the way the APIs worked and were more convenient. Same problem, > bigger delta per API rev vs only one rev. > > It's also worth looking at the changes we've actually been making here >> instead of theoretical examples. The amount of effort to make an >> application use 2.20 instead of 2.1 is pretty minimal. > > > Sure, but there is nothing in place to prevent that contrived example. The > first time an addition is made of what would have been an extension in the > past we will be there. [and no, this is in no way a defense of extensions > ;). > > If Identity had micro-versioned their way between V2 and v3 would the > other projects been able to convert faster due to not having to do it all > at once? > > You didn't have to convert from V2 to V3 all at once, and we didn't. I assume there is still some use of V2 in gate runs in addition to using V3. Keystone supports the V2 API on /v2.0 and the V3 API on /v3. So you could make some requests to V2 and other requests to V3. You could get a token using V2 and use it on V3, or get a token using V3 and use it to do V2 operations. You can't use new V3 features when accessing the V2 API (like domains). This is pretty much the same as your example of specifying a different version for the nova API on different requests (except they have a lot more than just 2 and 3). We also keep adding routes to v3 each release, so what operations are supported keeps changing. - Brant dt > > -- > > Dean Troyer > dtro...@gmail.com > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev