No way to move persistent volumes between namespaces

[smarterclayton]

When a user wants to migrate an application across namespaces, there needs to be an easy way to accomplish that (something that can be explained to a user in a few CLI steps). An admin really shouldn't have to be involved if the user has access to both PVCs. I.e. a "release to" annotation or similar.

[markturansky]

changing the namespace on the PVC and PV.Spec.ClaimRef would be all that's needed. What is an appropriate way of doing that?

[liggitt]

changing the namespace on the PVC and PV.Spec.ClaimRef would be all that's needed

Well, the PVC is namespaced, so you can't "change" the namespace on it... the new one with a different namespace is a different PVC. The trick is getting the PV to be ok with switching to a PVC in a different namespace without admin intervention.

[erinboyd]

What about the PV backing the PVC? That has to be considered in terms of permissions when doing the migration.

[markturansky]

the PV has the same permissions as before. We need only change pv.Spec.ClaimRef to point to the new PVC.

If we're not changing the existing PVC and instead pointing the PV at a new one, this can be accomplished in a single transaction. We just need to change the reference on the PV.

But PVs are admin objects and not available to mere mortals. The user's client would get rejected on update, even if the user has access to the various namespaces involved.

[smarterclayton]

Either the user has to set something on the existing PVC that gives it to something else, or there has to be an interface on the PVC that gives it up to someone else. Would have to be bound first.

[jeffvance]

What about an oc migrate(or move) project <old-proj> <new-proj> command? I did some upstream searching and didn't find a plan for this. Initially the command could just deal with moving PVCs but later there may be other pieces to move...

[markturansky]

We have a controller that handles claims. Seems easy enough to check for some var on the claim to trigger the move in the controller, which is an admin account.

How do we know the request to move from namespace $foo to namespace $bar is valid for that user?

[markturansky]

Nevermind. If the user can update the PVC in a namespace, (s)he has access to that namespace. Giving it to another is a choice, which should be allowed. Is that agreeable?

[liggitt]

Still need a way to signal the controller that the currently bound PVC concurs with trnsferring the PV to the new PVC, so the PV controller knows it is ok to update the PV binding

[markturansky]

Only the people in the namespace would be able to set the variable (probably an annotation). Is that not consent?

[smarterclayton]

The security implication is whether the remote user wants that PV. I think the sending user would have to set name and uid for safety at a minimum.