[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