Open Stack

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."
> 
> If you allow to group features under one microversion, that becomes even
> worse - you can have deployment that got microversion only partially.
> 
> For example, that's what I would call API discoverability:
> 
>  $ ironic has-capability foobar
>  true
> 
> and that's how it would play with versioning:
> 
>  $ ironic --ironic-api-version 1.2 has-capability foobar
>  false
>  $ ironic --ironic-api-version 1.6 has-capability foobar
>  true
> 
> On the contrary, the only thing that microversion tells me is that the
> server installation is based on a particular upstream commit.
> 
> To me these are orthogonal problems, and I believe they should be solved
> differently. Our disagreement is due to seeing them as one problem.

We should stop doing this everywhere in OpenStack. It is the absolute
worst experience ever.

Stop allowing people to disable features with config. there is literally
no user on the face of the planet for whom this is a positive thing.

1.5 should mean that your server has Set(A) of features. 1.6 should mean
Set(A+B) - etc. There should be NO VARIATION and any variation on that
should basically mean that the cloud in question is undeniably broken.

I understand that vendors and operators keep wanting to wank around with
their own narccisitic arrogance to "differentiate" from one another.

STOP IT

Seriously, it causes me GIANT amount of pain and quite honestly if I
wasn't tied to using OpenStack because I work on it, I would have given
up on it a long time ago because of evil stuff like this.

So, seriously - let's grow up and start telling people that they do not
get to pick and choose user-visible feature sets. If they have an unholy
obsession with a particular backend technology that does not allow a
public feature of the API to work, then they are deploying a broken
cloud and they need to fix it.


>>
>> Looking at your comments in the WG repo you also seem to only be
>> considering projects shipped at Major release versions (Kilo, Liberty).
>> Which might be true of Red Hat's product policy, but it's not generally
>> true that all clouds are at a release boundary. Continous Deployment of
>> OpenStack has been a value from Day 1, and many public clouds are not
>> using releases, but are using arbitrary points off of master.
> 
> I don't know why you decided I don't know it, but you're wrong.
> 
>> A
>> microversion describes when a changes happens so that applications
>> writers have a very firm contract about what they are talking to.
> 
> No, they don't. Too many things can modify behavior - see above.
> 
>>
>>     -Sean
>>
> 
> 
> __________________________________________________________________________
> 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
>