Create consensus on unbind

[pmorie]

In the F2F meetings in Boulder and Seattle, we made significant progress on the provision/bind workflow. We still need to explore the API flows for unbind. Some quick thoughts:

Indicating intention to unbind

The current precedent for this type of thing in kubernetes is to delete the resource to release it. For example, to unbind a PV from a PVClaim, you delete the claim. Here's a wrinkle for our specific situation: in the PV/PVC domain, you have something to reconcile against (the PV) if your controller misses the PVC delete. However, in the scenario of a controller missing the delete event for a Binding, there is nothing to reconcile against a priori. So, this seems to indicate that we need to have a way to preserve the Binding resource until we can be sure it is fully deleted and unbound at the broker. The pattern we have for this in Kubernetes is called 'finalization'.

Why finalization is needed - unbind example

Let's assume you have a Binding B to an Instance I of a ServiceClass S. There are a few permutations to talk through, but I'll keep it simple for now. Imagine the following:

1. The consumer wants to unbind B, so they delete B.
2. The controller receives a delete event for B and issues a DELETE to /v2/service_instances/:instance_id/service_bindings/:binding_id

From here it gets a little tricky -- do you allow the delete of B to happen, even if the broker doesn't respond with a 200? Here's where finalization comes in. The REST API for deleting a binding will instead of fully deleting the object manipulate the status in a way that indicates that the object is in a 'unbinding' condition. There are a vast number of details to understanding finalization, which I will gloss over here for brevity and ease of understanding. Essentially, part of a namespaces spec is the remaining finalizers that must run for the namespace to be fully deleted. When the first delete request happens, the namespace's status is updated to reflect the finalizing condition, and various controllers go to work deleting resources and updating the list of finalizers to remove themselves as they complete their work. There is a namespace controller that handles doing the final delete once the list of finalizers is empty, and the REST API only allows a 'full' delete of a namespace once that list is empty. We can leverage a similar pattern here to allow the following:

1. The consumer wants to unbind B and makes a delete request to the service catalog API server to do so.
2. The REST API updates B's status to reflect that it is deleting
3. The controller continues calling delete at the broker until receiving a 200
4. When the controller is satisfied that the delete at the broker succeeded, it can update B in a way that indicates that the finalization is complete, then delete B.

Deleting services / secrets / SIPs after unbinding

When a binding is undone, the resources created from that binding should be deleted. This should be implemented by a controller doing another part of finalization.

[duglin]

Sounds reasonable. Related to this is the entire discussion of how 'status' is represented in our resources - status vs conditions, etc. The topic Brian brought up.

[pmorie]

A similar concern exists for deprovision -- finalization of Instance is needed to support accepting a delete request and then having the service catalog controller take actions to ensure the deprovision is done for the Instance before it is ultimately deleted.

[arschles]

Has a decision been made on what happens to existing Bindings when a deletion/finalization is made on an Instance?

Sent from my iPhone

On Nov 19, 2016, at 18:52, Paul Morie notifications@github.com wrote:

A similar concern exists for deprovision -- finalization of Instance is needed to support accepting a delete request and then having the service catalog controller take actions to ensure the deprovision is done for the Instance before it is ultimately deleted.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[duglin]

if the delete on the instance is allowed to happen (due to it still being used) then I would think all bindings for that instance would be deleted too.

[pmorie]

@arschles

Has a decision been made on what happens to existing Bindings when a deletion/finalization is made on an Instance?

Not at all. I'm about to create an issue for it. I think this falls under 'deprovision'.

[pmorie]

Edited out the 'deprovision' bits of this issue -- spinning into a new issue.

[pmorie]

Background on the finalization pattern: https://github.com/kubernetes/kubernetes/blob/master/docs/design/namespaces.md#example-openshift-origin-managing-a-kubernetes-namespace

[pmorie]

We have since agreed on finalization and how the controller should handle this.