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