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.
Verified in 4.4.0-0.nightly-2020-02-17-131733 build on top of OSP 13 2020-01-15.3 puddle. The OCP installer finishes successfully: $ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.4.0-0.nightly-2020-02-17-131733 True False 16h Cluster version is 4.4.0-0.nightly-2020-02-17-131733 After running kubernetes/conformance test from origin release-4.4 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-84cc8d55b7-jkchk $ 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:0581