Open Stack

On 1/24/2017 2:05 AM, Alex Xu wrote:
> Unfortunately the device tag support in the API was broken in the old
> Microversion https://bugs.launchpad.net/nova/+bug/1658571, which thanks
> to Kevin Zheng to find out that.
>
> Actually there are two bugs, just all of them are about device tag. The
> first one [0] is a mistake in the initial introduce of device tag. The
> new schema only available for the version 2.32, when the request version
>> 2.32, the schema fallback to the old one.
>
> The second one [1] is that when we bump the API to 2.37, the network
> device tag was removed accidentally which also added in 2.32 [2].
>
> So the current API behavior is as below:
>
> 2.32: BDM tag and network device tag added.
> 2.33 - 2.36: 'tag' in the BDM disappeared. The network device tag still
> works.
> 2.37: The network device tag disappeared also.
>
> There are few questions we should think about:
>
> 1. Should we fix that by Microversion?
>     Thanks to Chris Dent point that out in the review. I also think we
> need to bump Microversion, which follow the rule of Microversion.
>
> 2. If we need Microversion, is that something we can do before release?
>     We are very close to the feature freeze. And in normal, we need spec
> for microversion. Maybe we only can do that in Pike. For now we can
> update the API-ref, and microversion history to notice that, maybe a
> reno also.
>
> 2. How can we prevent that happened again?
>    Both of those patches were reviewed multiple cycles. But we still
> miss that. It is worth to think about how to prevent that happened again.
>
>    Talk with Sean. He suggests stop passing plain string version to the
> schema extension point. We should always pass APIVersionRequest object
> instead of plain string. Due to "version == APIVersionRequest('2.32')"
> is always wrong, we should remove the '__eq__'. The developer should
> always use the 'APIVersionRequest.matches' [3] method.
>
>    That can prevent the first mistake we made. But nothing help for
> second mistake. Currently we only run the test on the specific
> Microversion for the specific interesting point. In the before, the new
> tests always inherits from the previous microversion tests, just like
> [4]. That can test the old API behavior won't be changed in the new
> microversion. But now, we said that is waste, we didn't do that again
> just like [5]. Should we change that back?
>
> Thanks
> Alex
>
> [0]
> https://review.openstack.org/#/c/304510/64/nova/api/openstack/compute/block_device_mapping.py
> [1] https://review.openstack.org/#/c/316398/37/nova/api/openstack/compute/schemas/servers.py@88
> [2] https://review.openstack.org/#/c/316398/37/nova/api/openstack/compute/schemas/servers.py@79
> [3] https://github.com/openstack/nova/blob/master/nova/api/openstack/api_version_request.py#L219
> [4] https://github.com/openstack/nova/blob/master/nova/tests/unit/api/openstack/compute/test_evacuate.py#L415
> [5] https://github.com/openstack/nova/blob/master/nova/tests/unit/api/openstack/compute/test_serversV21.py#L3584
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

First, thanks to Kevin and Alex for finding this issue and explaining it 
in detail so we can understand the scope.

This is a nasty unfortunate issue which I really wish we could just fix 
without a microversion bump but we have microversions for a reason, 
which is to fix issues in the API. In thinking about if this were the 
legacy 2.0 API, we always had a rule that you couldn't fix bugs in the 
API if they changed the behavior, no matter how annoying.

So let's fix this with a microversion. I don't think we need to hold it 
to the feature freeze deadline as it's a microversion only for a bug 
fix, it's not a new feature. So that's a compromise at least and gives 
us some time to get this done correctly and still have it fixed in 
Ocata. We'll also want to document this in the api-ref and REST API 
version history in whatever way makes it clear about the limitations 
between microversions.

As for testing, I think using a mix of test inheritance and using 
2.latest is probably a good step to take. I know we've had a mix of that 
in different places in the functional API samples tests, but there was 
never a clear rule about what do to with testing microversions and if 
you should use inheritance to build on existing tests.

-- 

Thanks,

Matt Riedemann