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-requ...@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
__________________________________________________________________________
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
