Open Stack

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
>