Open Stack

On Tue, Jul 26, 2016 at 12:14:03PM -0500, 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.

The only case where this will matter is for test classes that have an unbound
max microversion, which should be very few. It's only classes that specify a
higher minimum. The simple way around that is just change the max microversion
for those classes to 2.35 and it won't ever send a 2.36 request. For example:

http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/compute/volumes/test_attach_volume.py#n187

change 'latest' to 2.35 if it calls nova-network anywhere in that call path.
(as an aside to people unfamiliar with microversions in tempest that doesn't
mean send 'latest' on the wire but that all microversions are valid for this
test, ie it won't skip based on the min microversion in config)

However, this does raise a bigger issue about removing nova-network next cycle.
It's still the default a lot of places. We can't remove the tempest support
until newton eol (assuming an ocata removal) So we'll likely have to add a flag
or 2 to make sure we never use it on master, there will also be devstack,
devstack-gate, etc changes that will have to happen first too. But this is all
probably a topic better suited for another thread or even a summit discussion.

-Matt Treinish
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160726/ed646b53/attachment.pgp>