Open Stack

On 02/21/2016 12:59 PM, Duncan Thomas wrote:
> On 21 February 2016 at 19:34, Jay S. Bryant
> <jsbryant at electronicjungle.net <mailto:jsbryant at 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