Remain/Remove release-related PVC when release is deleted about rudder HOT 9 CLOSED

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?

from rudder.

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

from rudder.

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.

from rudder.

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.

from rudder.

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.

from rudder.

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

from rudder.

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.

from rudder.

+1

I prefer latter.

from rudder.

Discussed offline. All PVCs are left to Resource Center.

from rudder.