Open Stack

> -----Original Message-----
> From: Matt Riedemann [mailto:mriedemos at gmail.com]
> Sent: Tuesday, May 23, 2017 8:59 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] on the subject of when we should be deprecating
> API's in a release cycle
> 
> 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?
> 
[Amrith Kumar] Hmm, trove's unit tests are gating against u-c, so that may have been the reason. You may be correct, u-c changes are not gated on Trove yet and I hesitate to request that given how flaky our gate currently is. The container stuff is coming along nicely and is much more reliable so I may be able to have a reliable containerized version that can be tested against before long and then I will request gating u-c changes on Trove as well.

> 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.
> 

[Amrith Kumar] Yeah, but I won't try to hide behind that; we should have seen this coming. In fairness, looking at how the neutron stuff is implemented in Trove makes me believe that we have a refactoring project in the near future.

> --
> 
> Thanks,
> 
> Matt
> 
> __________________________________________________________________________
> 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