Re: [openstack-dev] [nova][manila] latest microversion considered dangerous
2015-08-29 2:07 GMT+08:00 Matt Riedemann mrie...@linux.vnet.ibm.com: On 8/28/2015 10:35 AM, Joe Gordon wrote: On Aug 28, 2015 6:49 AM, Sean Dague s...@dague.net mailto:s...@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-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][manila] latest microversion considered dangerous
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 dtant...@redhat.com mailto:dtant...@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-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kind Regards Valeriy Ponomaryov www.mirantis.com http://www.mirantis.com vponomar...@mirantis.com mailto:vponomar...@mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][manila] latest microversion considered dangerous
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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][manila] latest microversion considered dangerous
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 dtant...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kind Regards Valeriy Ponomaryov www.mirantis.com vponomar...@mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][manila] latest microversion considered dangerous
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 dtant...@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 dtant...@redhat.com mailto:dtant...@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-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kind Regards Valeriy Ponomaryov www.mirantis.com http://www.mirantis.com vponomar...@mirantis.com mailto:vponomar...@mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [nova][manila] latest microversion considered dangerous
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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][manila] latest microversion considered dangerous
On Aug 28, 2015 6:49 AM, Sean Dague s...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][manila] latest microversion considered dangerous
On 8/28/2015 10:35 AM, Joe Gordon wrote: On Aug 28, 2015 6:49 AM, Sean Dague s...@dague.net mailto:s...@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-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][manila] latest microversion considered dangerous
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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][manila] latest microversion considered dangerous
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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
