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.
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
