← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 2015388] [NEW] Deleting network does not remove network namespace

 

Public bug reported:

Environment: ML2/OVS

DevStack Version: 2023.2
Change: b10c06027273d125f2b8cd14d4b19737dfb94b94 Merge "Add config options for cinder nfs backend" 2023-03-27 14:20:04 +0000
OS Version: Ubuntu 22.04 jammy

While testing a fix for a bug on a recent devstack, I noticed that
network namespaces were not getting deleted when I deleted a network
with a subnet attached to it.

$ openstack network list
+--------------------------------------+----------+----------------------------------------------------------------------------+
| ID                                   | Name     | Subnets                                                                    |
+--------------------------------------+----------+----------------------------------------------------------------------------+
| 32171620-509d-498f-b0e1-b86c2fdc004e | shared   | 995701e4-7923-411f-b3d6-a0d9a6c22ca5                                       |
| 6cc3ff11-09a6-40a8-9765-a453fcb7bf2e | private  | d990dbe7-5658-46f7-b0a1-691a18444519, e7c91b4a-0595-42be-b777-6a2ee6d45113 |
| b2fbc798-3163-4696-9a12-75a4f0b7c3c7 | public   | 4be007ea-0a2a-48e2-94a2-15407ff11694, af06a026-7044-4284-b653-955c41685905 |
| cc47f423-c50b-4b06-b62b-6d2603eb5fa0 | mtu-1279 | 0664a3d9-3eb8-4503-86dd-aba78c02791c                                       |
+--------------------------------------+----------+----------------------------------------------------------------------------+

$ ip netns | grep cc47f423-c50b-4b06-b62b-6d2603eb5fa0
qdhcp-cc47f423-c50b-4b06-b62b-6d2603eb5fa0 (id: 6)

$ openstack network delete cc47f423-c50b-4b06-b62b-6d2603eb5fa0
$ openstack network list
+--------------------------------------+---------+----------------------------------------------------------------------------+
| ID                                   | Name    | Subnets                                                                    |
+--------------------------------------+---------+----------------------------------------------------------------------------+
| 32171620-509d-498f-b0e1-b86c2fdc004e | shared  | 995701e4-7923-411f-b3d6-a0d9a6c22ca5                                       |
| 6cc3ff11-09a6-40a8-9765-a453fcb7bf2e | private | d990dbe7-5658-46f7-b0a1-691a18444519, e7c91b4a-0595-42be-b777-6a2ee6d45113 |
| b2fbc798-3163-4696-9a12-75a4f0b7c3c7 | public  | 4be007ea-0a2a-48e2-94a2-15407ff11694, af06a026-7044-4284-b653-955c41685905 |
+--------------------------------------+---------+----------------------------------------------------------------------------+

$ ip netns | grep cc47f423-c50b-4b06-b62b-6d2603eb5fa0
qdhcp-cc47f423-c50b-4b06-b62b-6d2603eb5fa0 (id: 6)

I almost would have expected an error since there was a subnet here,
will have to re-check the API ref to see.

During one attempt I actually triggered a SubnetNotFound error, but
that's probably a different issue as it wasn't necessary to recreate
this.

** Affects: neutron
     Importance: Medium
     Assignee: Brian Haley (brian-haley)
         Status: New


** Tags: l3-ipam-dhcp

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2015388

Title:
  Deleting network does not remove network namespace

Status in neutron:
  New

Bug description:
  Environment: ML2/OVS

  DevStack Version: 2023.2
  Change: b10c06027273d125f2b8cd14d4b19737dfb94b94 Merge "Add config options for cinder nfs backend" 2023-03-27 14:20:04 +0000
  OS Version: Ubuntu 22.04 jammy

  While testing a fix for a bug on a recent devstack, I noticed that
  network namespaces were not getting deleted when I deleted a network
  with a subnet attached to it.

  $ openstack network list
  +--------------------------------------+----------+----------------------------------------------------------------------------+
  | ID                                   | Name     | Subnets                                                                    |
  +--------------------------------------+----------+----------------------------------------------------------------------------+
  | 32171620-509d-498f-b0e1-b86c2fdc004e | shared   | 995701e4-7923-411f-b3d6-a0d9a6c22ca5                                       |
  | 6cc3ff11-09a6-40a8-9765-a453fcb7bf2e | private  | d990dbe7-5658-46f7-b0a1-691a18444519, e7c91b4a-0595-42be-b777-6a2ee6d45113 |
  | b2fbc798-3163-4696-9a12-75a4f0b7c3c7 | public   | 4be007ea-0a2a-48e2-94a2-15407ff11694, af06a026-7044-4284-b653-955c41685905 |
  | cc47f423-c50b-4b06-b62b-6d2603eb5fa0 | mtu-1279 | 0664a3d9-3eb8-4503-86dd-aba78c02791c                                       |
  +--------------------------------------+----------+----------------------------------------------------------------------------+

  $ ip netns | grep cc47f423-c50b-4b06-b62b-6d2603eb5fa0
  qdhcp-cc47f423-c50b-4b06-b62b-6d2603eb5fa0 (id: 6)

  $ openstack network delete cc47f423-c50b-4b06-b62b-6d2603eb5fa0
  $ openstack network list
  +--------------------------------------+---------+----------------------------------------------------------------------------+
  | ID                                   | Name    | Subnets                                                                    |
  +--------------------------------------+---------+----------------------------------------------------------------------------+
  | 32171620-509d-498f-b0e1-b86c2fdc004e | shared  | 995701e4-7923-411f-b3d6-a0d9a6c22ca5                                       |
  | 6cc3ff11-09a6-40a8-9765-a453fcb7bf2e | private | d990dbe7-5658-46f7-b0a1-691a18444519, e7c91b4a-0595-42be-b777-6a2ee6d45113 |
  | b2fbc798-3163-4696-9a12-75a4f0b7c3c7 | public  | 4be007ea-0a2a-48e2-94a2-15407ff11694, af06a026-7044-4284-b653-955c41685905 |
  +--------------------------------------+---------+----------------------------------------------------------------------------+

  $ ip netns | grep cc47f423-c50b-4b06-b62b-6d2603eb5fa0
  qdhcp-cc47f423-c50b-4b06-b62b-6d2603eb5fa0 (id: 6)

  I almost would have expected an error since there was a subnet here,
  will have to re-check the API ref to see.

  During one attempt I actually triggered a SubnetNotFound error, but
  that's probably a different issue as it wasn't necessary to recreate
  this.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2015388/+subscriptions