Skip to content

Support for opt-in cleanup of PVCs #1391

Closed
@snarlysodboxer

Description

@snarlysodboxer

What did you do to encounter the bug?
Steps to reproduce the behavior:

  1. Use latest operator
  2. Use CI to apply MongoDBCommunity
  3. Attempt to use CI to cleanup MongoDBCommunity
  4. PVCs get left behind, external hacks required

What did you expect?
A clear and explicit opt-in way to configure a specific MongoDBCommunity to cause full cascading deletion including the PVCs. Many operators that deal with state have this feature for this very reason. For example with the postgres-operator you can set a specific annotation's value to match the object's name, in which case the operator will fully cleanup including the PVCs via ownerReferences. Without that annotation it will orphan the StatefulSet and therefore PVCs, helping to prevent mistakenly deleting stateful data. - Set that annotation only in your ephemeral CI testing envs, and you're pretty safe.

Even when you're migrating a production environment, once you're done, you want the operator to be able to clean up the old environment. The MongoDB Operator seems to be an outlier in not accounting for a full lifecycle.

What happened instead?
One can't just kubectl delete -f my-testing-env/, one also has to discover and manually delete the PVCs created by the MongoDBCommunity. This precludes the use of things like ArgoCD to deliver and cleanup ephemeral envs for CI. Even if CI just uses a bash script that executes kubectl commands, it makes the script suddenly needlessly complicated - just for Mongo.

Operator Information

  • Latest

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions