Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support PersistentVolumeClaimRetentionPolicy for statefulsets #208

Open
SatyaKuppam opened this issue Feb 23, 2025 · 0 comments
Open

Support PersistentVolumeClaimRetentionPolicy for statefulsets #208

SatyaKuppam opened this issue Feb 23, 2025 · 0 comments

Comments

@SatyaKuppam
Copy link
Contributor

SatyaKuppam commented Feb 23, 2025

As of Kubernetes v1.32 PersistentVolumeClaimRetention policy is enabled by default for statefulsets and is behind a feature gate for v1.31. This feature provides a K8s native way to manage orphaned PVCs, that is pretty similar to the existing deleteOrphanPvc config in the Druid CRD. By using this policy, we can control how orphaned PVCs will be treated:

persistentVolumeClaimRetentionPolicy:
   whenDelete: <true|false>
   whenScaled: <true|false>

Some folks might prefer persistentVolumeClaimRetention over deleteOrphanPvc because:

  • allows more granular control because its at the statefulset level, instead of deleteOrphanPvc which affects the entire Druid cluster. For example:
    • we might want to Retain historical PVCs because loading data from S3 might be expensive
    • but we might want to delete middlemanagers' PVCs on scale-downs
  • dont have to be bound by the deleteOrphanPvc's delayed deletion of 60s (ref)

I want to add this functionality in the nodeSpec if folks think its useful and I want to align on the following:

  • this makes sense only for statefulsets and not deployments
  • if the deleteOrphanPvc is set, then the persistentVolumeClaimRetention configuration is automatically ignored to allow for backward compatibility
  • this configuration only makes sense if StatefulSetAutoDeletePVC feature flag is set (ref).
    • I am actually not sure how to check for this. Any ideas?
  • this feature is only available from v1.31, but from the compatibility matrix (ref), the latest we support is v.1.30.1.
    • What do I have to do to use the > v.1.30 API?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant