/area API
/kind cleanup
/kind good-first-issue
Expected Behavior
It's a common misconception that folks can delete our system namespace (e.g. knative-serving) to "clean up" their cluster for a fresh installation.
Actual Behavior
Unfortunately, we install a lot of things that aren't deleted by deleting our system namespace, and some of those things block reinstallation. In particular the configmap webhook has no pods, and so it blocks configmap creations. This creates a chicken/egg problem because the webhook pods need those configmaps to start up properly.
Proposed Solution
I think the simplest solution would be to have our webhooks set up an OwnerReference to the namespace resource within which its target service lives. We used to do this for the webhook deployment, but removed that due to it being Cluster-scoped -> Namespaced (which isn't supported). However, Namespace is a cluster-scoped resource, so I think this would work.
/area API
/kind cleanup
/kind good-first-issue
Expected Behavior
It's a common misconception that folks can delete our system namespace (e.g.
knative-serving) to "clean up" their cluster for a fresh installation.Actual Behavior
Unfortunately, we install a lot of things that aren't deleted by deleting our system namespace, and some of those things block reinstallation. In particular the configmap webhook has no pods, and so it blocks configmap creations. This creates a chicken/egg problem because the webhook pods need those configmaps to start up properly.
Proposed Solution
I think the simplest solution would be to have our webhooks set up an OwnerReference to the namespace resource within which its target service lives. We used to do this for the webhook deployment, but removed that due to it being Cluster-scoped -> Namespaced (which isn't supported). However, Namespace is a cluster-scoped resource, so I think this would work.