> -----Original Message-----
> From: Matthew Treinish [mailto:mtrein...@kortar.org]
> Sent: 27 July 2016 02:36
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.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 [1], we can work
> > >> on the python-novaclient changes for this microversion.
> > >>
> > >> At the midcycle we agreed [2] 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.
> > >>
> > >> [1] https://review.openstack.org/#/c/337005/
> > >> [2] 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
