caicloud/rudder

Remain/Remove release-related PVC when release is deleted

kdada opened this issue · 9 comments

kdada commented

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:

  1. Delete all PVCs when release is deleted.
  2. Remain all PVCs and leave them to Volume Module.
  3. Keep a switch in release controller.
  4. Keep the switch in Release API.
xiaoq17 commented

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?

kdada commented

@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.

ddysher commented

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.

kdada commented

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.

ddysher commented

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.

pendoragon commented

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

xiaoq17 commented

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.

pendoragon commented

+1

I prefer latter.

kdada commented

Discussed offline. All PVCs are left to Resource Center.