[openstack-dev] [nova] Device tag in the API breaks in the old microversion

Zhenyu Zheng zhengzhenyulixi at gmail.com
Wed Jan 25 01:51:14 UTC 2017


Thanks Alex for raising this up widely, as Chinese holiday is comming and
Alex and me might be away for a week, And it will be better to fix this
faster, so thanks Artom taking over to fix it :)

On Wed, Jan 25, 2017 at 7:50 AM, Ghanshyam Mann <ghanshyammann at gmail.com>
wrote:

>
> On Wed, Jan 25, 2017 at 1:18 AM, Matt Riedemann <mriedemos at gmail.com>
> wrote:
>
>> 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/openstac
>>> k/compute/block_device_mapping.py
>>> [1] https://review.openstack.org/#/c/316398/37/nova/api/openstac
>>> k/compute/schemas/servers.py at 88
>>> [2] https://review.openstack.org/#/c/316398/37/nova/api/openstac
>>> k/compute/schemas/servers.py at 79
>>> [3] https://github.com/openstack/nova/blob/master/nova/api/opens
>>> tack/api_version_request.py#L219
>>> [4] https://github.com/openstack/nova/blob/master/nova/tests/uni
>>> t/api/openstack/compute/test_evacuate.py#L415
>>> [5] https://github.com/openstack/nova/blob/master/nova/tests/uni
>>> t/api/openstack/compute/test_serversV21.py#L3584
>>>
>>>
>>>
>>> ____________________________________________________________
>>> ______________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.op
>>> enstack.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.
>>
>
> ​+1 for fixing in Ocata itself. We have fix up just need to put that under
> new version. I can modify the tests to cover this bug scenario. ​
>
>
>
>>
>> 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.
>
>> Also along with that, I'd like to add tempest job with 'latest'
> microversion (we thought of this earlier) and run as nv on nova side.
> Current tests will fail due to behavior changes in versions and need
> version cap etc. We can start capping/fixing tempest tests​ and make as
> much as tests to pass with 'latest'.
>
> During new version changes, that job can clearly tell what kind of
> behavior is changing and we can catch that.
>
>
>
>
>>
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170125/93933c18/attachment.html>


More information about the OpenStack-dev mailing list