> -----Original Message----- > From: Matt Riedemann [mailto:mriede...@gmail.com] > Sent: Tuesday, May 23, 2017 8:59 PM > To: openstack-dev@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.ku...@gmail.com > > > > > > > > > > ______________________________________________________________________ > > ____ 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 > > > > 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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ 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
