[openstackclient][all] Nova-network removal in OSC
Hi, While doing some other cleanup in the openstackclient network code, I noticed there were still places where it had Nova-network compatibility. I have proposed a patch to remove it all at [0], but Stephen reminded me that there could be users that need this (Rackspace? [1]) and as the client should support all clouds, removing it might break them. From what I can remember it was in the Havana cycle in 2013 that Neutron became the standard and maybe Newton (?) where we started to de-emphasize Nova-network. Is that a long enough time to call something obsolete and remove it? Please respond here or in the review if this is a bad idea, it's currently blocked with a -2 so it doesn't merge. Thanks! -Brian, Neutron PTL [0] https://review.opendev.org/c/openstack/python-openstackclient/+/981613 [1] https://docs-ospc.rackspace.com/cloud-networks/v2/
On Fri, 2026-04-10 at 12:46 -0400, Brian Haley wrote:
Hi,
While doing some other cleanup in the openstackclient network code, I noticed there were still places where it had Nova-network compatibility. I have proposed a patch to remove it all at [0], but Stephen reminded me that there could be users that need this (Rackspace? [1]) and as the client should support all clouds, removing it might break them.
From what I can remember it was in the Havana cycle in 2013 that Neutron became the standard and maybe Newton (?) where we started to de-emphasize Nova-network. Is that a long enough time to call something obsolete and remove it?
Please respond here or in the review if this is a bad idea, it's currently blocked with a -2 so it doesn't merge.
I should note that despite my -2, I have no objections to doing this once we know that we're not going to break anyone badly. The code that handles the switching between nova-network and neutron is some of the nastiest in OSC and I'd be glad to be rid of it. Cheers, Stephen
Thanks!
-Brian, Neutron PTL
[0] https://review.opendev.org/c/openstack/python-openstackclient/+/981613 [1] https://docs-ospc.rackspace.com/cloud-networks/v2/
Hi all! Why is the support of Nova Network different from, let's say, Nova/Cinder drivers? If something has no active CI job for a while, it should be considered as dead/not-supported/not-maintainable, deprecated and removed at some point. вт, 14 квіт. 2026 р. о 18:53 Stephen Finucane <stephenfin@redhat.com> пише:
On Fri, 2026-04-10 at 12:46 -0400, Brian Haley wrote:
Hi,
While doing some other cleanup in the openstackclient network code, I noticed there were still places where it had Nova-network compatibility. I have proposed a patch to remove it all at [0], but Stephen reminded me that there could be users that need this (Rackspace? [1]) and as the client should support all clouds, removing it might break them.
From what I can remember it was in the Havana cycle in 2013 that Neutron became the standard and maybe Newton (?) where we started to de-emphasize Nova-network. Is that a long enough time to call something obsolete and remove it?
Please respond here or in the review if this is a bad idea, it's currently blocked with a -2 so it doesn't merge.
I should note that despite my -2, I have no objections to doing this once we know that we're not going to break anyone badly. The code that handles the switching between nova-network and neutron is some of the nastiest in OSC and I'd be glad to be rid of it.
Cheers, Stephen
Thanks!
-Brian, Neutron PTL
[0]
https://review.opendev.org/c/openstack/python-openstackclient/+/981613
-- Best regards, Andriy Kurilin.
On Wed, Apr 15, 2026, at 10:54 AM, Andriy Kurilin wrote:
Hi all!
Why is the support of Nova Network different from, let's say, Nova/Cinder drivers? If something has no active CI job for a while, it should be considered as dead/not-supported/not-maintainable, deprecated and removed at some point.
Because OpenStack Client is user facing. As a user I don't get to choose which drivers and deployment options the clouds I have to work with configure/support/deploy with. You cannot aggressively drop support for things users deal with without creating problems. You don't have to look very far to find examples where people do this and create issues. Setuptools, Docker, and so on. Measured removals with checks to ensure the impacts are likely what we expect seem reasonable which is what seems to be happening here. But care is appreciated as a user that talks to a handful of clouds that are all very different and from different eras.
ср, 15 квіт. 2026 р. о 19:59 Clark Boylan <cboylan@sapwetik.org> пише:
On Wed, Apr 15, 2026, at 10:54 AM, Andriy Kurilin wrote:
Hi all!
Why is the support of Nova Network different from, let's say, Nova/Cinder drivers? If something has no active CI job for a while, it should be considered as dead/not-supported/not-maintainable, deprecated and removed at some point.
Because OpenStack Client is user facing. As a user I don't get to choose which drivers and deployment options the clouds I have to work with configure/support/deploy with. You cannot aggressively drop support for things users deal with without creating problems.
If we do not have a CI for a specific feature, we cannot guarantee that it works. Shipping possible broken code does not improve the user experience. For smaller features, the risk is smaller, for service support is bigger:) Pinning openstacksdk&python-openstackclient on the operator side seems more reasonable.
You don't have to look very far to find examples where people do this and create issues. Setuptools, Docker, and so on.
Measured removals with checks to ensure the impacts are likely what we expect seem reasonable which is what seems to be happening here. But care is appreciated as a user that talks to a handful of clouds that are all very different and from different eras.
-- Best regards, Andriy Kurilin.
On 2026-04-15 20:29:43 +0200 (+0200), Andriy Kurilin wrote: [...]
If we do not have a CI for a specific feature, we cannot guarantee that it works. Shipping possible broken code does not improve the user experience. For smaller features, the risk is smaller, for service support is bigger:) Pinning openstacksdk&python-openstackclient on the operator side seems more reasonable. [...]
As someone who operates multi-cloud applications that interface simultaneously with very ancient and very new OpenStack public clouds, I'll just note that what you suggest is to basically operate multiple client versions in tandem. It's not impossible, but also probably a bit user-hostile as recommendations go. If this is really the best we can do, then we should as a community be thinking about ways to make it easier for operators of multi-cloud applications to juggle multiple client versions and figure out which ones work with which cloud providers. -- Jeremy Stanley
On 4/15/26 1:58 PM, Clark Boylan wrote:
On Wed, Apr 15, 2026, at 10:54 AM, Andriy Kurilin wrote:
Hi all!
Why is the support of Nova Network different from, let's say, Nova/Cinder drivers? If something has no active CI job for a while, it should be considered as dead/not-supported/not-maintainable, deprecated and removed at some point.
Because OpenStack Client is user facing. As a user I don't get to choose which drivers and deployment options the clouds I have to work with configure/support/deploy with. You cannot aggressively drop support for things users deal with without creating problems. You don't have to look very far to find examples where people do this and create issues. Setuptools, Docker, and so on.
Measured removals with checks to ensure the impacts are likely what we expect seem reasonable which is what seems to be happening here. But care is appreciated as a user that talks to a handful of clouds that are all very different and from different eras.
Thanks for the responses here. Just to give an example of what might break, for example, running: $ openstack security group create ... will use the neutron endpoint if it exists, if not it will use use the nova endpoint. So in practice, removing the code will only cause issues with pre-Havana clouds using nova-network. Those are most likely unicorns at this point, which is why I started the discussion. Removing the cruft from OSC was a nice side-effect. I can try and bring this up in the operators radio hour next Friday during the PTG, but I'm guessing (hoping) nova-network is no longer in use. -Brian
As far as Rackspace goes nova-networks API hasn’t worked for at least 10 years so it’s not going to be that. -- Doug
On Apr 10, 2026, at 11:47 AM, Brian Haley <haleyb.dev@gmail.com> wrote:
Hi,
While doing some other cleanup in the openstackclient network code, I noticed there were still places where it had Nova-network compatibility. I have proposed a patch to remove it all at [0], but Stephen reminded me that there could be users that need this (Rackspace? [1]) and as the client should support all clouds, removing it might break them.
From what I can remember it was in the Havana cycle in 2013 that Neutron became the standard and maybe Newton (?) where we started to de-emphasize Nova-network. Is that a long enough time to call something obsolete and remove it?
Please respond here or in the review if this is a bad idea, it's currently blocked with a -2 so it doesn't merge.
Thanks!
-Brian, Neutron PTL
[0] https://review.opendev.org/c/openstack/python-openstackclient/+/981613 [1] https://docs-ospc.rackspace.com/cloud-networks/v2/
participants (6)
-
Andriy Kurilin
-
Brian Haley
-
Clark Boylan
-
Doug Goldstein
-
Jeremy Stanley
-
Stephen Finucane