> -----Original Message----- > From: Matthew Treinish [mailto:mtrein...@kortar.org] > Sent: 27 July 2016 02:36 > To: OpenStack Development Mailing List (not for usage questions) > <firstname.lastname@example.org> > Subject: Re: [openstack-dev] [nova] Next steps for proxy API deprecation > > On Tue, Jul 26, 2016 at 01:21:53PM -0400, Sean Dague wrote: > > On 07/26/2016 01:14 PM, Matt Riedemann wrote: > > > On 7/26/2016 11:59 AM, Matt Riedemann wrote: > > >> Now that the 2.36 microversion change has merged , we can work > > >> on the python-novaclient changes for this microversion. > > >> > > >> At the midcycle we agreed  to also return a 404 for network > > >> APIs, including nova-network (which isn't a proxy), for consistency > > >> and further signaling that nova-network is going away. > > >> > > >> In the client, we agreed to soften the impact for network CLIs by > > >> determining if the latest microversion supported will fail (so will > > >> we send >=2.36) and rather than fail, send 2.35 instead (if the > > >> user didn't specifically specify a different version). However, > > >> we'd emit a warning saying this is deprecated and will go away in > > >> the first major client release (in Ocata? after nova-network is > > >> removed? after Ocata is released?). > > >> > > >> We should probably just deprecate any CLIs/APIs in > > >> python-novaclient today that are part of this server side API > > >> change, including network CLIs/APIs in novaclient. The baremetal > > >> and image proxies in the client are already deprecated, and the volume > proxies were already removed. > > >> That leaves the network proxies in the client. > > >> > > >> From my notes, Dan Smith was going to work on the novaclient > > >> changes for > > >> 2.36 to not fail and use 2.35 - unless anyone else wants to > > >> volunteer to do that work (please speak up). > > >> > > >> We can probably do the network CLI/API deprecations in the client > > >> in parallel to the 2.36 support, but need someone to step up for > > >> that. I'll try to get it started this week if no one else does. > > >> > > >>  https://review.openstack.org/#/c/337005/ > > >>  https://etherpad.openstack.org/p/nova-newton-midcycle > > >> > > > > > > I forgot to mention Tempest. We're going to have to probably put a > > > max_microversion cap in several tests in Tempest to cap at 2.35 (or > > > change those to use Neutron?). There are also going to be some > > > response schema changes like for quota usage/limits, I'm not sure if > > > anyone is looking at this yet. We could also get it done after > > > feature freeze on 9/2, but I still need to land the get-me-a-network > > > API change which is microversion 2.37 and has it's own Tempest test, > > > although that test relies on Neutron so I might be OK for the most part. > > > > Is that strictly true? We could also just configure all the jobs for > > Nova network to set max microversion at 2.35. That would probably be > > more straight forward way of approaching this, and make it a bit more > > clear how serious we are here. > > > > Yeah, for the gate that should work. By default tempest sends the minimum > microversion based on the config and the test requirements. So we should > never send 2.36 unless the test says it's minimum required microversion is > >=2.36. Setting the max at 2.35 would mean we skip those tests. My bigger > concern is for people using tempest outside of the gate. I still think we > should set a max microversion on any test classes that call nova's network > apis to make sure they're properly skipped just in case someone sets the min > microversion in the tempest config at 2.36. (assuming such a test class exists > at all, I don't actually know) Unless you thinking failing there is the > correct > way to do it?
Yes, I also prefer the approach of capping the tests instead of jobs. But along with that we might need to make sure the same tests coverage Tempest provides if min_microversion is set >2.35 in config. For example, if we cap the tests (calls nova-network) with max_microversion = 2.35 then, we might need to implement/modify those tests to start using neutron which can be run if config's min_microversion is set > 2.35. There are two type of test cases- 1. Test only tests nova-network APIs - Example: https://github.com/openstack/tempest/tree/master/tempest/api/compute/floating_ips 2. Test testing other scenario using nova-network - Example: https://github.com/openstack/tempest/blob/master/tempest/api/compute/servers/test_server_rescue.py 1st case if all ok to cap and leave it skip for >2.35. But for 2nd case, I feel we should not leave them skip if config's min_microversion > 2.35 which mean leaving those scenario untested(if min_microversion >2.35). There are 2 options for 2nd case: 1. Implement duplicate tests by using the neutron APIs - This will be duplicate tests but needed because of testing nova-network till newton EOL. 2. Or modify those to switch from nova-network to neutron. - If we do not care about nova-network testing even for stable branches where it is not deprecated. Thanks gmann __________________________________________________________________________ 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