Re: [openstack-dev] on the subject of when we should be deprecating API's in a release cycle
> -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
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? 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 __ 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-dev] on the subject of when we should be deprecating API's in a release cycle
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
