<div dir="ltr">Dmitriy,<div><br></div><div>New tests, that cover new functionality already know which API version they require. So, even in testing, it is not needed. All other existing tests do not require API update.</div><div><br></div><div>So, I raise hand for restricting "latest".</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 28, 2015 at 10:20 AM, Dmitry Tantsur <span dir="ltr"><<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 08/27/2015 09:38 PM, Ben Swartzlander wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Manila recently implemented microversions, copying the implementation<br>
from Nova. I really like the feature! However I noticed that it's legal<br>
for clients to transmit "latest" instead of a real version number.<br>
<br>
THIS IS A TERRIBLE IDEA!<br>
<br>
I recommend removing support for "latest" and forcing clients to request<br>
a specific version (or accept the default).<br>
</blockquote>
<br></span>
I think "latest" is needed for integration testing. Otherwise you have to update your tests each time new version is introduced.<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Allowing clients to request the "latest" microversion guarantees<br>
undefined (and likely broken) behavior* in every situation where a<br>
client talks to a server that is newer than it.<br>
<br>
Every client can only understand past and present API implementation,<br>
not future implementations. Transmitting "latest" implies an assumption<br>
that the future is not so different from the present. This assumption<br>
about future behavior is precisely what we don't want clients to make,<br>
because it prevents forward progress. One of the main reasons<br>
microversions is a valuable feature is because it allows forward<br>
progress by letting us make major changes without breaking old clients.<br>
<br>
If clients are allowed to assume that nothing will change too much in<br>
the future (which is what asking for "latest" implies) then the server<br>
will be right back in the situation it was trying to get out of -- it<br>
can never change any API in a way that might break old clients.<br>
<br>
I can think of no situation where transmitting "latest" is better than<br>
transmitting the highest version that existed at the time the client was<br>
written.<br>
<br>
-Ben Swartzlander<br>
<br>
* Undefined/broken behavior unless the server restricts itself to never<br>
making any backward-compatiblity-breaking change of any kind.<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Kind Regards<br>Valeriy Ponomaryov<br><a href="http://www.mirantis.com" target="_blank">www.mirantis.com</a><br><a href="mailto:vponomaryov@mirantis.com" target="_blank">vponomaryov@mirantis.com</a><br></div></div>
</div>