On 08/04/2016 01:17 PM, Chris Friesen wrote:
On 08/04/2016 09:28 AM, Edward Leafe wrote:
The idea that by specifying a distinct microversion would somehow
guarantee
an immutable behavior, though, is simply not the case. We discussed
this at
length at the midcycle regarding the dropping of the nova-network
code; once
that's dropped, there won't be any way to get that behavior no matter
what
microversion you specify. It's gone. We signal this with deprecation
notices,
release notes, etc., and it's up to individuals to move away from
using that
behavior during this deprecation period. A new microversion will never
help
anyone who doesn't follow these signals.
I was unable to attend the midcycle, but that seems to violate the
original description of how microversions were supposed to work. As I
recall, the original intent was something like this:
At time T, we remove an API via microversion X. We keep the code around
to support it when using microversions less than X.
At some later time T+i, we bump the minimum microversion up to X. At
this point nobody can ever request the older microversions, so we can
safely remove the server-side code.
Have we given up on this? Or is nova-network a special-case?
This is how Ironic works with microversions today, yes. However, in Nova
we've unfortunately taken the policy that we will probably *never* bump
the minimum microversion.
I personally find this extremely distasteful as I hate all the crap that
needs to sit around along with all the conditionals in the code that
have to do with continuing to support old behaviour.
If it were up to me, the Nova project would just say to operators and
library/SDK develpers: if you want feature foo, then the tradeoff is
that the minimum microversion is going up to X. Operators can choose to
continue on the old code or indicate to their users that they are
running a minimum newer version of the Compute API and users will need
to use a library that passes that minimum version header at least.
IMHO we have gone out of our way to cater to mythical users who under no
circumstances should ever be affected by changes in an API. Enough is
enough. It's time we took back some control and cleaned up a bunch of
technical debt and poor API design vestigial tails by raising the
minimum microversion of the Compute API.
And no, the above isn't saying "to hell with our users". It's a simple
statement that we cannot be beholden to a small minority of users,
however vocal, that wish that nothing would ever change. These users can
continue to deploy CentOS4 or Ubuntu 10.04 or libvirt 0.9.8 [1] if they
wish and not upgrade OpenStack, but that shouldn't mean that we as a
project cannot start tidying up our own house.
OK, frustration vented... I'm heading back in for reviews on cleaning up
unit test cruft in the image backend that Matt Booth pushed.
Best,
-jay
[1] Hmm, interesting that Nova requires a minimum libvirt version of
1.2.1 nowadays. So, we're happy to say to operators "in order to use
modern Nova you need to upgrade to 1.2.1 libvirt" but we aren't willing
to tell those same operators "upgrading to this version of Nova will
mean your users will have to make a small change to the way they
interact with the Compute API". Really, this doesn't jive with me.
__________________________________________________________________________
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
