upstream k8s reuse "Service catalog follows namespace lifecycle" (create namespace if one does not exist by denying resource creation if the namespace does not exist)

[pmorie]

In the k8s core, there is an admission controller that autoprovisions a namespace that does not already exist when a namespaced resource is created for that namespace. We need to have equivalent functionality in service-catalog.

[pmorie]

cc @derekwaynecarr, since this is relevant to your interests

[duglin]

Isn't that a little scary? A simple fat-finger could create a ton of extra namespaces over time.

[pmorie]

I'm not sure that I see what is scary about it. We do the same thing for every namespaced resource in kubernetes.

[duglin]

that doesn't make it any less scary :-)

In a previous discussion you were talking about how it may be "a good thing" that we allow dangling pointers because the other end might not be there yet. If so, why isn't this treated the same way? If things were consistent we would try to create all missing resources at the other end of a dangling resource. But clearly we don't. Not sure why namespaces should be auto-created when others aren't. How many other resources are auto-created? Is this documented some place?

[arschles]

Note that #565 will not fix this issue, but will mitigate because helm can (but won't in all cases) auto-provision namespaces

[derekwaynecarr]

Namespace auto provision admission controller is deprecated. k8s uses NamespaceLifecycle which forces namespace to be previously created prior to creation of the resource. It also enforces new resources cannot be created when a namespace is undergoing termination. Service catalog should assume the same and reuse. I plan to help out on the namespace related issues soon.

[derekwaynecarr]

This thread reminds me that I need to remove those plugins in 1.8 kube.

[derekwaynecarr]

@pmorie -- can we relabel this issue as follows:

"Service catalog follows namespace lifecycle"

To summarize what would need to be done would be the following:

service catalog apiserver runs an admission controller that does the following:

1. verifies existence and phase of the k8s namespace prior to admission of any namespaced resource
2. associates the service catalog w/ the k8s namespace by adding a service catalog token into the Namespace.Spec.Finalizers list via the Finalize client action

service catalog controller-manager runs a controller that does the following:

1. watches k8s namespaces pending deletion
2. removes the service catalog namespaced resources
3. removes the service catalog token from the namespace to allow the k8s server to finally purge the namespace

let's chat later this week on the best way to re-use code for the above (near and long-term).

[arschles]

I am ok with doing this, but not in MVP 3. We have more pressing issues right now, and can get far by putting a note in our documentation indicating that the namespace must exist prior to creating a Binding (in practice, that's the only time we really need it), and must persist throughout the lifecycle of the Binding and app that uses the secret created by the controller.

I am moving this to Later

[MHBauer]

Is this #2258 ?

[nilebox]

Based on the comment #586 (comment) I think we should close this issue. We've switched to the upstream NamespaceLifecycle admission controller in #2258, and sounds like Kubernetes doesn't automatically create namespaces anymore.

[nilebox]

Also, we should never have a Service Catalog resource existing when namespace is missing - this is a bug, see #2254 and upstream PR kubernetes/kubernetes#66932

Closing this issue and marking #2254 with 1.0.0 milestone.