<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 02/20/2016 04:42 PM, Duncan Thomas
wrote:<br>
</div>
<blockquote
cite="mid:CAOyZ2aGiDXcW1cY9SuB7V+DXNRze7KZnmfDC+=CobU8FuhOJjA@mail.gmail.com"
type="cite">
<p dir="ltr"><br>
On 20 Feb 2016 00:21, "Walter A. Boring IV" <<a
moz-do-not-send="true" href="mailto:walter.boring@hpe.com"><a class="moz-txt-link-abbreviated" href="mailto:walter.boring@hpe.com">walter.boring@hpe.com</a></a>>
wrote:</p>
<p dir="ltr">> 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. </p>
<p dir="ltr">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.</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
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.<br>
<br>
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.<br>
<br>
Jay<br>
<br>
</body>
</html>