settingsLogin | Registersettings

[openstack-dev] [nova][manila] "latest" microversion considered dangerous

0 votes

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).

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: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Aug 27, 2015 in openstack-dev by Ben_Swartzlander (5,940 points)   2 3 6

9 Responses

0 votes

On 8/27/2015 2: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).

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: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Makes sense to me.

I see we note that you can do this in the nova devref but there isn't
any warning about using it:

http://docs.openstack.org/developer/nova/api_microversion_dev.html?highlight=latest#

--

Thanks,

Matt Riedemann


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 28, 2015 by Matt_Riedemann (48,320 points)   3 8 21
0 votes

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: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 28, 2015 by Dmitry_Tantsur (18,080 points)   2 3 7
0 votes

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.

So, I raise hand for restricting "latest".

On Fri, Aug 28, 2015 at 10:20 AM, Dmitry Tantsur dtantsur@redhat.com
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:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomaryov@mirantis.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 28, 2015 by Valeriy_Ponomaryov (1,980 points)   1 4
0 votes

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 <dtantsur@redhat.com
dtantsur@redhat.com> 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:
    OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
    
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomaryov@mirantis.com vponomaryov@mirantis.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 28, 2015 by Dmitry_Tantsur (18,080 points)   2 3 7
0 votes

I don't know if this is really a big problem. IMO, even with microversions
you shouldn't be implementing things that aren't backwards compatible
within the major version. I thought the benefit of microversions is to know
if a given feature exists within the major version you are using. I would
consider a breaking change to be a major version bump. If we only do a
microversion bump for a backwards incompatible change then we are just
using microversions as major versions.

-Alex

On Fri, Aug 28, 2015 at 3:45 AM, Dmitry Tantsur dtantsur@redhat.com wrote:

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 <dtantsur@redhat.com
dtantsur@redhat.com> 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:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<
http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe

--
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomaryov@mirantis.com vponomaryov@mirantis.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 28, 2015 by Alex_Meade (920 points)   1
0 votes

On 08/28/2015 09:32 AM, Alex Meade wrote:
I don't know if this is really a big problem. IMO, even with
microversions you shouldn't be implementing things that aren't backwards
compatible within the major version. I thought the benefit of
microversions is to know if a given feature exists within the major
version you are using. I would consider a breaking change to be a major
version bump. If we only do a microversion bump for a backwards
incompatible change then we are just using microversions as major versions.

In the Nova case, Microversions aren't semver. They are content
negotiation. Backwards incompatible only means something if time's arrow
only flows in one direction. But when connecting to a bunch of random
OpenStack clouds, there is no forced progression into the future.

While each service is welcome to enforce more compatibility for the sake
of their users, one should not assume that microversions are semver as a
base case.

I agree that 'latest' is basically only useful for testing. The
python-novaclient code requires a microversion be specified on the API
side, and on the CLI side negotiates to the highest version of the API
that it understands which is supported on the server -
https://github.com/openstack/python-novaclient/blob/d27568eab50b10fc022719172bc15666f3cede0d/novaclient/__init__.py#L23

-Sean

--
Sean Dague
http://dague.net


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 28, 2015 by Sean_Dague (66,200 points)   4 8 14
0 votes

On Aug 28, 2015 6:49 AM, "Sean Dague" sean@dague.net wrote:

On 08/28/2015 09:32 AM, Alex Meade wrote:

I don't know if this is really a big problem. IMO, even with
microversions you shouldn't be implementing things that aren't backwards
compatible within the major version. I thought the benefit of
microversions is to know if a given feature exists within the major
version you are using. I would consider a breaking change to be a major
version bump. If we only do a microversion bump for a backwards
incompatible change then we are just using microversions as major
versions.

In the Nova case, Microversions aren't semver. They are content
negotiation. Backwards incompatible only means something if time's arrow
only flows in one direction. But when connecting to a bunch of random
OpenStack clouds, there is no forced progression into the future.

While each service is welcome to enforce more compatibility for the sake
of their users, one should not assume that microversions are semver as a
base case.

I agree that 'latest' is basically only useful for testing. The

Sounds like we need to update the docs for this.

python-novaclient code requires a microversion be specified on the API
side, and on the CLI side negotiates to the highest version of the API
that it understands which is supported on the server -

https://github.com/openstack/python-novaclient/blob/d27568eab50b10fc022719172bc15666f3cede0d/novaclient/__init__.py#L23

Considering how unclear these two points appear to be, are they clearly
documented somewhere? So that as more projects embrace microversions, they
don't end up having the same discussion.

    -Sean

--
Sean Dague
http://dague.net


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 28, 2015 by Joe_Gordon (24,620 points)   2 5 8
0 votes

On 8/28/2015 10:35 AM, Joe Gordon wrote:

On Aug 28, 2015 6:49 AM, "Sean Dague" <sean@dague.net
sean@dague.net> wrote:

On 08/28/2015 09:32 AM, Alex Meade wrote:

I don't know if this is really a big problem. IMO, even with
microversions you shouldn't be implementing things that aren't
backwards
compatible within the major version. I thought the benefit of
microversions is to know if a given feature exists within the major
version you are using. I would consider a breaking change to be a major
version bump. If we only do a microversion bump for a backwards
incompatible change then we are just using microversions as major
versions.

In the Nova case, Microversions aren't semver. They are content
negotiation. Backwards incompatible only means something if time's arrow
only flows in one direction. But when connecting to a bunch of random
OpenStack clouds, there is no forced progression into the future.

While each service is welcome to enforce more compatibility for the sake
of their users, one should not assume that microversions are semver as a
base case.

I agree that 'latest' is basically only useful for testing. The

Sounds like we need to update the docs for this.

python-novaclient code requires a microversion be specified on the API
side, and on the CLI side negotiates to the highest version of the API
that it understands which is supported on the server -

https://github.com/openstack/python-novaclient/blob/d27568eab50b10fc022719172bc15666f3cede0d/novaclient/__init__.py#L23

Considering how unclear these two points appear to be, are they clearly
documented somewhere? So that as more projects embrace microversions,
they don't end up having the same discussion.

Yar: https://review.openstack.org/#/c/218403/

    -Sean

--
Sean Dague
http://dague.net


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--

Thanks,

Matt Riedemann


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 28, 2015 by Matt_Riedemann (48,320 points)   3 8 21
0 votes

2015-08-29 2:07 GMT+08:00 Matt Riedemann mriedem@linux.vnet.ibm.com:

On 8/28/2015 10:35 AM, Joe Gordon wrote:

On Aug 28, 2015 6:49 AM, "Sean Dague" <sean@dague.net
sean@dague.net> wrote:

On 08/28/2015 09:32 AM, Alex Meade wrote:

I don't know if this is really a big problem. IMO, even with
microversions you shouldn't be implementing things that aren't
backwards
compatible within the major version. I thought the benefit of
microversions is to know if a given feature exists within the major
version you are using. I would consider a breaking change to be a
major
version bump. If we only do a microversion bump for a backwards
incompatible change then we are just using microversions as major
versions.

In the Nova case, Microversions aren't semver. They are content
negotiation. Backwards incompatible only means something if time's
arrow
only flows in one direction. But when connecting to a bunch of random
OpenStack clouds, there is no forced progression into the future.

While each service is welcome to enforce more compatibility for the
sake
of their users, one should not assume that microversions are semver as
a
base case.

I agree that 'latest' is basically only useful for testing. The

Sounds like we need to update the docs for this.

python-novaclient code requires a microversion be specified on the API
side, and on the CLI side negotiates to the highest version of the API
that it understands which is supported on the server -

https://github.com/openstack/python-novaclient/blob/d27568eab50b10fc022719172bc15666f3cede0d/novaclient/__init__.py#L23

Considering how unclear these two points appear to be, are they clearly
documented somewhere? So that as more projects embrace microversions,
they don't end up having the same discussion.

Yar: https://review.openstack.org/#/c/218403/

Also agree with warning this. ++ for the doc update.

    -Sean

--
Sean Dague
http://dague.net


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--

Thanks,

Matt Riedemann


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 31, 2015 by Alex_Xu (8,960 points)   1 3 3
...