Open Stack

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.