On 08/28/2015 09:34 AM, Valeriy Ponomaryov wrote:
Dmitriy,
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.
Yeah, but you can't be sure that your change does not break the world,
until you merge it and start updating tests. Probably it's not that
important for projects who have their integration tests in-tree though..
So, I raise hand for restricting "latest".
On Fri, Aug 28, 2015 at 10:20 AM, Dmitry Tantsur <[email protected]
<mailto:[email protected]>> wrote:
On 08/27/2015 09:38 PM, Ben Swartzlander wrote:
Manila recently implemented microversions, copying the
implementation
from Nova. I really like the feature! However I noticed that
it's legal
for clients to transmit "latest" instead of a real version number.
THIS IS A TERRIBLE IDEA!
I recommend removing support for "latest" and forcing clients to
request
a specific version (or accept the default).
I think "latest" is needed for integration testing. Otherwise you
have to update your tests each time new version is introduced.
Allowing clients to request the "latest" microversion guarantees
undefined (and likely broken) behavior* in every situation where a
client talks to a server that is newer than it.
Every client can only understand past and present API
implementation,
not future implementations. Transmitting "latest" implies an
assumption
that the future is not so different from the present. This
assumption
about future behavior is precisely what we don't want clients to
make,
because it prevents forward progress. One of the main reasons
microversions is a valuable feature is because it allows forward
progress by letting us make major changes without breaking old
clients.
If clients are allowed to assume that nothing will change too
much in
the future (which is what asking for "latest" implies) then the
server
will be right back in the situation it was trying to get out of
-- it
can never change any API in a way that might break old clients.
I can think of no situation where transmitting "latest" is
better than
transmitting the highest version that existed at the time the
client was
written.
-Ben Swartzlander
* Undefined/broken behavior unless the server restricts itself
to never
making any backward-compatiblity-breaking change of any kind.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kind Regards
Valeriy Ponomaryov
www.mirantis.com <http://www.mirantis.com>
[email protected] <mailto:[email protected]>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
