+++ This bug was initially created as a clone of Bug #1785136 +++ If the kuryr controller gets restarted, there is still chances of leaking networks and subnet resources. This may happen if it gets restarted after creating the network resources for a namespace and before adding the kuryrnet object (or if that fails and it gets restarted before the rollback). This ends up with networks/subnets that don't have a kuryrnet object associated. In that situation, if the namespace gets deleted, the created network/subnet is left behind, and the clean up mechanism does not account for them either.
Hi, Please add information about how to verify
You can run the OCP QE tests, check if there is any network leftover due to failing test or kuryr-kubernetes restarts. And if that so, kill the kuryr-controller and check that the networks get deleted
Verified in 4.3.0-0.nightly-2020-01-06-185654 build on top of OSP 13 2019-12-06.2 puddle. The OCP installer finishes successfully: $ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.3.0-0.nightly-2020-01-06-185654 True False 175m Cluster version is 4.3.0-0.nightly-2020-01-06-185654 After running kubernetes/conformance test from origin release-4.3 there are no leftovers, and kuryr-controller pod has been restarted several times during the tests, which means that it has removed the leftovers upon the restart. Creating manually a ns, deleting the kuryrnet, the ns and kuryr-controller pod also worked, there were no network or subnet related to it. $ oc new-project test $ oc delete ns test; oc delete kuryrnet ns-test; oc -n openshift-kuryr delete pod kuryr-controller-bdd967688-h9nzx $ openstack network list | grep test; openstack subnet list | grep test no leftovers related to test namespace
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:0062