[openstack-dev] [Ironic] When to bump the microversion?

Dmitry Tantsur dtantsur at redhat.com
Thu Jun 4 15:54:58 UTC 2015

On 06/04/2015 05:43 PM, Sean Dague wrote:
> 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.

I disagree with all said above, but putting aside discussion about ideal 
vs real world, my point actually boils down to:
if you want feature discovery (or as you call it - contract), make it 
explicit. Create API for it. Here you're upset with users guessing 
features - and you invent one more way to guess them. Probably working 
in ideal world, but still a guessing game. And pretty inconvenient to 
use (to test, to document), I would say.

And within Ironic community (including people deploying from master), 
I'm still waiting to hear requests for such feature at all, but that's 
another question.

> 	-Sean

More information about the OpenStack-dev mailing list