[openstack-dev] on the subject of when we should be deprecating API's in a release cycle

Matt Riedemann mriedemos at gmail.com
Wed May 24 00:58:39 UTC 2017


On 5/23/2017 7:50 PM, Amrith Kumar wrote:
> TL;DR
> 
> When IaaS projects in OpenStack deprecate their API's after milestone 1, it
> puts PaaS projects in a pickle. I think it would be much better for PaaS
> projects if the IaaS projects could please do their deprecations well before
> milestone-1
> 
> The longer issue:
> 
> OK, the guy from Trove is bitching again. The Trove gate is broken (again).
> This time, it appears to be because Trove was using a deprecated Nova
> Networking API call, and even though everyone and their brother knew that
> Nova Networking was gone-gone, Trove never got the memo, and like a few
> others got hit by it.
> 
> But the fact of the matter is this, it happened. This has happened in
> previous releases as well where at milestone 2 we are scrambling to fix
> something because an IaaS project did a planned deprecation.
> 
> I'm wondering whether we can get a consensus around doing these earlier in
> the cycle, like before milestone-1, so other projects which depend on the
> API have a chance to handle it with enough time to test and verify.
> 
> Just to be explicitly clear, I AM NOT pointing fingers at Nova. I knew that
> NN was gone, just that a couple of API's remained in use and we got bit in
> the glueteus maximus. I asked Matt for help to find out what API's had been
> deprecated, he almost immediately helped me with a list and I'm working
> through getting them fixed (Thanks Matt).
> 
> I'm merely raising the generic question of whether or not planned
> deprecations should be done before Milestone 1.
> 
> Thanks for reading the longer version ...
> 
> --
> Amrith Kumar
> amrith.kumar at gmail.com
> 
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

The novaclient changes to deprecate the networking proxy CLIs and APIs 
was done in the Newton release. They were removed and released in 8.0.0 
which was milestone 1 of the Pike release. So what are you specifically 
asking for here? Maybe Trove didn't get hit until recently because 
novaclient 8.0.0 wasn't pulled into upper-constraints? That might have 
been why it seems recent for Trove. I think the u-c change was gating on 
Horizon fixing their stuff, but maybe u-c changes aren't gated on Trove 
unit tests?

Admittedly the python API binding deprecations in novaclient weren't 
using the python warnings module with the DeprecationWarning, which 
we've been pretty consistent about with other API deprecations in the 
novaclient (like with the volume, image and baremetal proxy APIs). We 
dropped the ball on the networking ones though. We have docs in 
novaclient about how to deprecate things, but it's mostly CLI-focused so 
I'm going to update that to be explicit about deprecation warnings in 
the API bindings too.

-- 

Thanks,

Matt



More information about the OpenStack-dev mailing list