[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