Remain/Remove release-related PVC when release is deleted

Question

Remain/Remove release-related PVC when release is deleted

kdada opened this issue 7 years ago · comments

We have a mechanism that we will delete PVCs created by chart template when release is deleted. But StatefulSet have an opposite mode. It remains all PVCs created by itself.

The two behaviors is divisive. So release controller should decide a consistent way to handle all PVCs in release.

Four ways:

Delete all PVCs when release is deleted.
Remain all PVCs and leave them to Volume Module.
Keep a switch in release controller.
Keep the switch in Release API.

Qin Xiao · Answer 1 · Fri Nov 10 2017 12:13:11 GMT+0800 (China Standard Time)

What's the difference with a Deployment with volumes and a StatefulSet with volumes (besides controller's yaml format) ? Volume lifecycle might be a key point.

Stateful -> StatefulSet, data/volumes live even when application ends(deleted), user could use in other application or remove it manually.
Stateless -> Deployment, data/volumes only live when application lives, recycled when application ends.

We could keep it with sufficient tooltip explanations in product to avoid misunderstanding. Does it make sense?

Wei Guo · Answer 2 · Fri Nov 10 2017 15:46:37 GMT+0800 (China Standard Time)

@xiaoq17
Deployment's volumes are created by ReleaseController, but StatefulSet's volumes are created by Kubernetes StatefulSetController. ReleaseController don't know it.

ReleaseController will clean all garbages when a release is deleted except PVCs created by StatefulSet. The behavior may make users confused.

Deyuan Deng · Answer 3 · Fri Nov 10 2017 17:55:03 GMT+0800 (China Standard Time)

Are we creating volume via posting PVC to kubernetes and have it create PV for us?

Deployment's volumes are created by ReleaseController

Adding a switch sounds like the most flexible approach. My data shouldn't have separate meaning on what type of application I'm deploying, even for stateless apps, retaining data is beneficial for situation like cold start.

Wei Guo · Answer 4 · Fri Nov 10 2017 18:26:01 GMT+0800 (China Standard Time)

Are we creating volume via posting PVC to kubernetes and have it create PV for us?

Not all. If a user create a volume with type Dynamic, ReleaseController will create a PVC for it.

The main concern is that ReleaseController don't know which PVC is created by StatefulSetController. It causes that ReleaseController is forced to leave them in cluster.

The simplest way is that ReleaseController leaves all PVCs in cluster whoever it is created by.

Deyuan Deng · Answer 5 · Fri Nov 10 2017 19:58:57 GMT+0800 (China Standard Time)

What is the reclaim policy for PV created here?

ReleaseController will create a PVC for it.

No information provided via StatefulSetController? Sounds like we can send a patch...

The main concern is that ReleaseController don't know which PVC is created by StatefulSetController

This is fine if we want to deliver the feature quickly; but it's better to have a switch though.

The simplest way is that ReleaseController leaves all PVCs in cluster whoever it is created by.

Pengcheng Tang · Answer 6 · Mon Nov 13 2017 11:18:57 GMT+0800 (China Standard Time)

I'd prefer having a switch in API and let users decide whether to keep the pvc.

Qin Xiao · Answer 7 · Mon Nov 13 2017 19:41:41 GMT+0800 (China Standard Time)

I'd prefer having a switch in API and let users decide whether to keep the pvc.

More precisely, the switch might exist in :

create API as a spec: application.autoRemovePVC == true/false
delete API as a param or a action:
- "你确定要删除应用 XXX 吗？(checkbox) 同时删除全部应用数据：volume1, volume2"
- 类似于 "你确定要卸载程序 XXX 吗？(checkbox) 同时删除用户数据和存档"

I prefer latter.

Pengcheng Tang · Answer 8 · Mon Nov 13 2017 20:30:23 GMT+0800 (China Standard Time)

+1

I prefer latter.

Wei Guo · Answer 9 · Thu Dec 14 2017 13:55:13 GMT+0800 (China Standard Time)

Discussed offline. All PVCs are left to Resource Center.