settingsLogin | Registersettings

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

0 votes

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@gmail.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked May 24, 2017 in openstack-dev by amrith.kumar_at_gmai (3,580 points)   2 3

2 Responses

0 votes

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@gmail.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 24, 2017 by mriedemos_at_gmail.c (15,720 points)   2 6 11
0 votes

-----Original Message-----
From: Matt Riedemann [mailto:mriedemos@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.kumar@gmail.com


____ OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 24, 2017 by amrith.kumar_at_gmai (3,580 points)   2 3
...