On 06/04/2015 11:27 AM, Dmitry Tantsur wrote:
> On 06/04/2015 05:03 PM, Sean Dague wrote:
>> On 06/04/2015 10:50 AM, Dmitry Tantsur wrote:
>>> On 06/04/2015 04:40 PM, Ruby Loo wrote:
>>>> Hi,
>>>>
>>>> In Kilo, we introduced microversions but it seems to be a
>>>> work-in-progress. There is an effort now to add microversion into the
>>>> API-WG's guidelines, to provide a consistent way of using microversions
>>>> across OpenStack projects [1]. Specifically, in the context of this
>>>> email, there is a proposed guideline for when to bump the microversion
>>>> [2].
>>>
>>> As I understand this guideline tells to bump microversion on every
>>> change which I strongly -1 as usual. Reason: it's bump for the sake of
>>> bump, without any direct benefit for users (no, API discoverability is
>>> not one, because microversion do not solve it).
>>>
>>> I'll post the same comment to the guideline.
>>
>> Backwards compatible API adds with no user signaling is a fallacy
>> because it assumes the arrow of time flows only one way.
>>
>> If at version 1.5 you have a resource that is
>>
>> foo {
>> "bar": ...
>> }
>>
>> And then you decide you want to add another attribute
>>
>> foo {
>> "bar": ...
>> "baz": ...
>> }
>>
>> And you don't bump the version, you'll get a set of users that use a
>> cloud with baz, and incorrectly assume that version 1.5 of the API means
>> that baz will always be there. Except, there are lots of clouds out
>> there, including ones that might be at the code commit before it was
>> added. Because there are lots of deploys in the world, your users can
>> effectively go back in time.
>>
>> So now your API definition for version 1.5 is:
>>
>> "foo, may or may not contain baz, and there is no way of you knowing if
>> it will until you try. good luck."
>>
>> Which is pretty aweful.
>
> Which is not very different from your definition. "Version 1.5 contains
> feature xyz, unless it's disabled by the configuration or patched out
> downstream. Well, 1.4 can also contain the feature, if downstream
> backported it. So good luck again."
The whole point of interop is you can't call it OpenStack if you are
patching it downstream to break the upstream contract. Microversions are
a contract.
Downstream can hack code all they want, it's no longer OpenStack when
they do. If they are ok with it, that's fine. But them taking OpenStack
code and making something that's not OpenStack is beyond the scope of
the problem here. This is about good actors, acting in good faith, to
provide a consistent experience to application writers.
-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
