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
__________________________________________________________________________
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
