Dogface2k commented on PR #14424: URL: https://github.com/apache/cloudstack/pull/14424#issuecomment-6433050145
Could the legacy fallback be changed so retrying deletion cannot remove another cluster's unmarked rule? At `f38b135`, consider cluster A with tagged rules and legacy cluster B with unmarked rules on the same ACL. With `networkCleanup=false`, deletion removes A's ACL rules before releasing its public IP. If the management process is interrupted between those steps, the startup scanner retries A in `Destroying`. A's tagged rules are then absent, so the empty-reason fallback can remove B's remaining matching rule. The fix needs to avoid treating 'no tagged rules found' as proof that a matching unmarked rule belongs to A. A regression test can cover this by calling the real cleanup method twice, updating the DAO result after the first removal, and checking that B's rule is never revoked on the second call. Source at this head: [fallback](https://github.com/apache/cloudstack/blob/f38b13579e902e923c4cf82ece6ecae62f13f26f/plugins/integrations/kubernetes-service/src/main/java/com/cloud/kubernetes/cluster/actionworkers/KubernetesClusterResourceModifierActionWorker.java#L680), [deletion order](https://github.com/apache/cloudstack/blob/f38b13579e902e923c4cf82ece6ecae62f13f26f/plugins/integrations/kubernetes-service/src/main/java/com/cloud/kubernetes/cluster/actionworkers/KubernetesClusterDestroyWorker.java#L192), [startup retry](https://github.com/apache/cloudstack/blob/f38b13579e902e923c4cf82ece6ecae62f13f26f/plugins/integrations/kubernetes-service/src/main/java/com/cloud/kubernetes/cluster/KubernetesClusterManagerImpl.java#L2921). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
