On 21 February 2016 at 19:34, Jay S. Bryant <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. -- Duncan Thomas
__________________________________________________________________________ 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