You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 26, 2023. It is now read-only.
The "should not delete subnamespace" test in delete_crd_tests.go is flaky and fails maybe 20% of the time. This is fairly important because this is our only line of defense when uninstalling HNC - when you delete the CRDs, the subnamespaces are not supposed to be deleted.
According to the logs, HNC simply fails to notice that the CRDs are being deleted. A subsequent reconcile about 0.1s later does notice that the CRDs are being deleted, but by then it's too late - we've already started deleting the subnamespace. In other words, there's a race condition.
I'm asking some apiserver experts if there's a better way to solve this.
The text was updated successfully, but these errors were encountered:
Per the controller-runtime folks, while the default client uses the cache, we can create our own controller-runtime client that doesn't use the cache. And per @liggitt , that's the best way we have to determine if a CR's being deleted due to its CRD being deleted.
The "should not delete subnamespace" test in
delete_crd_tests.go
is flaky and fails maybe 20% of the time. This is fairly important because this is our only line of defense when uninstalling HNC - when you delete the CRDs, the subnamespaces are not supposed to be deleted.According to the logs, HNC simply fails to notice that the CRDs are being deleted. A subsequent reconcile about 0.1s later does notice that the CRDs are being deleted, but by then it's too late - we've already started deleting the subnamespace. In other words, there's a race condition.
I'm asking some apiserver experts if there's a better way to solve this.
The text was updated successfully, but these errors were encountered: