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

Alex Xu soulxu at gmail.com
Mon Aug 31 01:52:48 UTC 2015


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

>
>
> On 8/28/2015 10:35 AM, Joe Gordon wrote:
>
>>
>> On Aug 28, 2015 6:49 AM, "Sean Dague" <sean at dague.net
>> <mailto:sean at 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 at 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 at 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 at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150831/60fd9eeb/attachment.html>


More information about the OpenStack-dev mailing list