Open Stack

On 02/20/2016 04:42 PM, Duncan Thomas wrote:
>
>
> On 20 Feb 2016 00:21, "Walter A. Boring IV" <walter.boring at hpe.com 
> <mailto:walter.boring at hpe.com>> wrote:
>
> > Not that I'm adding much to this conversation that hasn't been said 
> already, but I am pro v2 API, purely because of how painful and long 
> it's been to get the official OpenStack projects to adopt the v2 API 
> from v1.
>
> I think there's a slightly different argument here. We aren't taking 
> away the v2 API, probably ever. Clients that are satisfied with it can 
> continue to use it, as it is, forever. For clients that aren't trying 
> to do anything beyond the current basics will quite possibly be happy 
> with that. Consumers have no reason to change over without compelling 
> value from the change - that will come from what we implement on top 
> of microversions, or not. Unlike the v1 transition, we aren't trying 
> to get rid of v2, just stop changing existing semantics of it.
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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.

Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160221/978bd2d0/attachment.html>