[openstack-dev] [Nova] Some thoughts on API microversions
jaypipes at gmail.com
Thu Aug 4 20:31:00 UTC 2016
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
>> 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
>> microversion you specify. It's gone. We signal this with deprecation
>> 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
>> 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  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.
 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.
More information about the OpenStack-dev