Description
UPDATE: During the daily, it was mentioned that if the individual Service objects for each Pod have the owner reference set, then Kubernetes will clean these Services automatically when the Pods are deleted. It was decided that this issue is not blocked.
Blocked by: stackabletech/hdfs-operator#174 - it makes sense to first NodePort handling to the listener operator before implementing this issue.
Currently our operators will not act on removed information from the CR in some/most/all cases.
One example:
HBase operator has three roles (master, regionServer, restServer). If I create a HBase server CR with a restServer component and then remove it later (entirely, not setting replicas to 0) our operator will not clean up the STS that belongs to this role.
Proposed solution
Use the ClusterResource
struct from operator-rs to manage Kubernetes resources belonging to a Cluster object. An example of its usage can be found in the Superset Operator: https://github.com/stackabletech/superset-operator/blob/main/rust/operator-binary/src/superset_controller.rs#L241
Acceptance criteria
- This is done when all stale Kubernetes resources are cleaned up. A resource becomes stale when it's not part of the current cluster definition anymore.
-
ZNode
resources are not deleted because the operator cannot know if they are stale or not. -
PersistentVolumeClaims
used by the cluster are never deleted by the operator. - There is at least one test.
- Documentation on operator implementation is updated with information regarding handling of stale resources.
- Upgrade to the latest version of
operator-rs
(0.25
at the moment).
NOTE: This is part of an epic (stackabletech/issues#203) and might not apply to this operator. If that is the case please comment on this issue and just close it. This issue was created as part of a special bulk creation operation.
Metadata
Metadata
Assignees
Type
Projects
Status