persistentVolumeReclaimPolicy - currently set to "delete"

Is there a reason why this is “delete” and not “retain” ?

1 Like

Mostly because it is within the spirit of automation and operator handling.

With Operator you can either keep the PVCs when cluster is deleted (it is by default) or do a complete clean up with the finalizer - delete-psmdb-pvc.

Why do you think we should have Retain? I see it only as the case for protecting data in case of manual PVCs deletion.

1 Like

I see it only as the case for protecting data in case of manual PVCs deletion.

Exactly - a developer deleted a GKE cluster by mistake (yea … I know …) and it would be nice if the data related stuff would be left intact. Let’s say someone does delete the cluster in PROD, then it’s still ok to delete the data related resources manually.

1 Like

Got it! :slight_smile: Well, reclaim policy is something dictated by StorageClass, not PVC.

The quickest solution here would be to modify the storage class that you use. GKE’s standard storage class:

allowVolumeExpansion: true
kind: StorageClass
  annotations: "true"
  creationTimestamp: "2022-06-20T08:17:48Z"
  labels: EnsureExists
  name: standard
  resourceVersion: "368"
  uid: 6942539b-a89f-4f26-a1b4-865fead29015
  type: pd-standard
reclaimPolicy: Delete
volumeBindingMode: Immediate

Change reclaimPolicy here.

Our Operator creates PVCs, but Reclaim Policy is set on PV level. I’m not sure if it is possible to dynamically change PVc reclaim policy through PVC resource in k8s. Maybe I’m wrong.

Will modifying the storage class help in your case? You can have on StorageClass for prod workloads and always keep the data, and another StorageClass with delete, not to keep the junk.