On Aug 4, 2016, at 12:17 PM, Chris Friesen <chris.frie...@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 __________________________________________________________________________ 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
