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 <ghanshyamm...@gmail.com> wrote: > > On Wed, Jan 25, 2017 at 1:18 AM, Matt Riedemann <mriede...@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@88 >>> [2] https://review.openstack.org/#/c/316398/37/nova/api/openstac >>> k/compute/schemas/servers.py@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ 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