Open Stack

On Aug 4, 2016, at 12:17 PM, Chris Friesen <chris.friesen at windriver.com> 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?

Yes, because raising the minimum doesn’t just remove the deprecated thing (in this case, nova-network), but also removes the ability to use *all* of the older microversions. So in this case, we are creating a new microversion that simply signals “nova-network is no longer here”. It doesn’t act like the original intent on microversions (preservation of older APIs).

-- Ed Leafe