Open adejanovski opened 1 year ago
Note: this is closely related to #961.
As I'm digging into the code I'm encountering more questions:
checkDeletion
which handles the deletion of the whole cluster, and checkDcDeletion
which handles a single DC (if it's been removed from the cluster spec). However they don't share any code, which feels like a wasted opportunity for reuse.checkDeletion
removes Stargate, Reaper, deployments, services and configMaps. checkDcDeletion
only removes Stargate and Reaper. Decommissioning a DC does indeed leave at least one configMap behind (tested on a very simple cluster, there's probably more in complex scenarios).checkDcDeletion
looks up the components by exact name. checkDeletion
deletes every cluster sub-component in the current namespace. This works now but is something we'll need to keep in mind if we factor the code (two DCs can exist in the same namespace, so we can't reuse the shotgun approach for decommission).deleteDeployments
and deleteServices
were only added for Medusa. Why can't we use controller references there too?In fact, I think we could generalize the use of controller references. As long as every remote object we create is owned by the CassandraDatacenter
(directly or transitively), we shouldn't need to do anything beyond deleting the DC.
I'm going to experiment with that.
In controllers/k8ssandra/cleanup.go we delete all the objects that are tied to a deleted K8ssandraCluster object. The
deleteDeployments()
,deleteServices()
anddeleteConfigMaps()
could benefit from the following improvements:┆Issue is synchronized with this Jira Story by Unito ┆Issue Number: K8OP-90