On 02/21/2016 12:59 PM, Duncan Thomas wrote: > On 21 February 2016 at 19:34, Jay S. Bryant > <jsbry...@electronicjungle.net <mailto:jsbry...@electronicjungle.net>> > wrote: > > Spent some time talking to Sean about this on Friday afternoon and > bounced back and forth between the two options. At first, /v3 made > the most sense to me ... at least it did at the meetup. With people > like Sean Dague and Morgan Fainberg weighing in with concerns, it > seems like we should reconsider. Duncan, your comment here about > customers moving when they are ready is somewhat correct. That, > however, I am concerned is a a small subset of the users. I think > many users want to move but don't know any better. That was what we > encountered with our consumers. They didn't understand that they > needed to update the endpoint and couldn't figure out why their new > functions weren't working. > > So, I am leaning towards going with the /v2 endpoint and making sure > that the clients we can control are set up properly and we put > safety checks in the server end. I think that may be the safest way > to go. > > > So we can't get users to change endpoints, or write our libraries to > have sensible defaults, but we're somehow going to magically get > consumers to do the much harder job of doing version probes in their > code/libraries so that they don't get surprised by unexpected results? > This seems to be entirely nuts. If 'they' can't change endpoints (and we > can't make the libraries we write just do the right thing without > needing to change endpoints) then how are 'they' expected to do the > probing magic that will be required at some unpredictable poin tin the > future, but which you'll get away without until then? > > This would also make us inconsistent with the other projects that have > implemented microversions - so we're changing a known working pattern, > to try to avoid the problem of a user having to get their settings right > if they want new functionality, and hoping this doesn't introduce > entirely predictable and foreseeable bugs in the future that can't > actually be fixed except by checking/changing every client library out > there? There's no way that's a sensible API design.
Not entirely. Nova did a seperate endpoint mostly because we actually had an entirely duplicate wsgi stack (which was going to be v3). We needed 2 endpoints to make sure that the base microversion was indistinguishable. Manilla did a dedicated endpoint for philosophical reasons. Ironic just extended the /v1 in place. -Sean -- Sean Dague http://dague.net __________________________________________________________________________ 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