Open Stack

On 01/25/2017 06:16 AM, Monty Taylor wrote:
<snip>
> I have quibble with the current microversions construct. It's mostly
> semantic in nature, and I _think_ it's not valid/useful - but I'm going
> to describe it here just so that I've said it and we can all acknowledge
> it and move on.
>
> My concern is with the prefix "micro". What gets presented to the user
> now is a "major" api version that is essentially useless, and a
> monotonoically increasing single version number that does not indicate
> whether a given version introduced a breaking change or not.
>
> I LIKE the mechanism. It works well - I do not think using it is
> burdensome or bad for the user so far. But it's not "micro". It's
> _essentially_ "every 'microversion' bump must be treated as a major
> version bump, we just moved it to a construct that doesn't involve
> deploying 40 different rest endpoints.
>
> There are ways in which we could use the mechanism while still using
> structured content to convey some amount of meaning to a user so that
> client consumers don't have to write matrixes of "if this cloud has max
> microversion of 27, then do this, otherwise do this other thing" for all
> of the microversions.
>
> That said - it's WAY better than the other thing - at least so far in
> the way I'm seeing nova use it.
>
> So I imagine it's just me quibbling over the word 'micro' and wanting
> something more like libtool's version:revision:age construct which
> calculates for a given library and consumer whether or not a library can
> be expected to be usable in a dynamic linking context. (this is a
> different construct from semver, but turns out is handy when you have a
> single client that may need to consume multiple different api providers)

I can definitely understand an issue with the naming. The naming grew 
organically out of the Nova v3 struggles. It was a name that 
distinguished it from Major versions, and far enough away from Semver 
words to help disabuse people that this was semver. Which continues to 
be a struggle.

I'd suggestion a new bike shed on names, except, we seem to have at 
least built context around what we mean by microversions now in our 
community, and I'd had to backslide on 2 years of education there.

It's probably time to build more of a primer back into the api-ref site, 
maybe an area on common concepts.

<snip>
>> Also, when suppressing or not suppressing which user base is more
>> important? The users that exist now or the users to come? This may
>> sound like a snarky or idle question, but it's a real one: Is it
>> true that we do, as a general rule, base our development on existing
>> users and not people who have chosen not to use "the product" for
>> some reason?
>
> We have a GIANT install base - but the tools that can work consistently
> across that install base is small. If we continue to chase phantom maybe
> users at the expense of the users we have currently, I'm pretty sure
> we'll end up where linux on the desktop has. I believe we stopped be
> able to legitimately make backwards incompatible change around havana.

Right, I think that has been the constant question. And I agree that 
taking care of our existing users, at the cost of not being able to 
clean everything up, is the right call.

<snip>
>
> Finding this:
>
> http://docs.openstack.org/developer/nova/api_microversion_history.html
>
> Is hard. I saw it for the first time 3 days ago. Know why? It's in the
> nova developer docs, not in the API docs. It's a great doc.

Yeh, we need to get that reflected in api-ref. That's a short term todo 
I can probably bang out before the release. It was always intended to 
surface more broadly, but until new api-ref it really wasn't possible.

	-Sean

-- 
Sean Dague
http://dague.net