Description of the problem: Cluster pool entry in UI should be removed only when all clusters in the pool have been uninstalled Release version: Operator snapshot version: ACM 2.5.0-DOWNSTREAM-2022-04-12-04-50-40 MCE 2.0.0-DOWNANDBACK-2022-04-12-04-34-15 OCP version: Browser Info: Steps to reproduce: 1. Create cluster pool with size = 1 > cluster created successfully 2. Delete the cluster pool in step 1 Actual results: The cluster pool entry is deleted immediately in UI even though the deprovisioning of pool clusters is still in progress Expected results: Additional info:
It looks like the hive design. The clusterpool deleting will not wait the clusterdeployment. @efried Could you help to confirm if it is the reasonable behavior or if hive has plan to change it?
Can confirm this is how the clusterpool controller is designed [1] -- but note the speculative comment I added as part of an unrelated PR questioning whether we should do exactly as you suggest. Thinking about it more deeply, it would also be reasonable to throttle the deletions so as not to violate the pool's maxConcurrent. If this is something you think should be pursued, please open a HIVE-* jira card for discussion. We would consider it a feature request, not a bug fix. [1] https://github.com/openshift/hive/blob/20fd254763d5a7a873d5c202a0054ac7c0a3da01/pkg/controller/clusterpool/clusterpool_controller.go#L830-L835
Thanks @efried I have opened a jira issue for this: https://issues.redhat.com/browse/HIVE-1809 And will close this one.
Cool. I'm making some edits to that card. While you're waiting for that work to be discussed, prioritized, and implemented, here's a workaround that could probably be implemented in ACM pretty easily: When customer requests deletion of the ClusterPool, ACM could: - (Optional) Edit the ClusterPool.spec.maxConcurrent, e.g. unsetting it so all the deletions will happen at once rather than being throttled. - (Optional) Delete all ClusterClaims associated with the pool. These _will_ wait until their respective CD is gone; so (asynchronously) wait for them to actually disappear. - Scale the ClusterPool.spec.size to zero. Wait for ClusterPool.status.size to reach zero - Delete the ClusterPool.
@efried Thank you. @sweimer @kcormier I am not sure if we should fix the issue with the issue with workaround https://bugzilla.redhat.com/show_bug.cgi?id=2075653#c4 What do you think about this?
I don't think we should do any workarounds in the UI. The ClusterPool should be displayed as long as the resource exists. In the past, I have actually received bugs because the ClusterPool did not disappear right away (I guess this is when there are existing ClusterClaims) since the ClusterPool was still listed with no indication it was being deleted, unless you expand it and see the clusters being destroyed. See https://github.com/stolostron/backlog/issues/16943
fyi: https://issues.redhat.com/browse/HIVE-1557
Thanks Sho. I've closed HIVE-1809 in favor of HIVE-1557 and copied over my notes. There are some open questions about how we should design this -- PTAL.