Open Stack

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.openstack.org?subject:unsubscrib
>> e
>> 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: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/6e92e044/attachment.html>