github-actions[bot] commented on issue #14159: URL: https://github.com/apache/cloudstack/issues/14159#issuecomment-5664848105
## ๐ฏ Triage report Detailed, well-researched bug report: scaling a CKS cluster with separate etcd nodes down from 2โ1 workers fails with error 530 due to SSH firewall/port-forward rule selection logic incorrectly matching an etcd SSH rule instead of the control/worker rule, leaving the cluster in an Alert state with a stale worker count. ### ๐ Assessment | Dimension | Value | Reasoning | |---|---|---| | **Type** | type:bug | Clear functional defect in rule-selection logic causing an operation failure. | | **Component** | component:kubernetes, component:networking | Affects CKS cluster scaling (kubernetes-service plugin) and firewall/port-forwarding rule management. | | **Severity** | Severity:Major | Scale-down operation fails and leaves the cluster in Alert state with inconsistent worker count and removed SSH access, but core cluster/API functionality otherwise remains available and no data loss occurs. | | **Labels** | type:bug, component:kubernetes, component:networking, Severity:Major | See above. | | **Coding agent** | Suitable | Reporter pinpoints the exact faulty selector logic in `KubernetesClusterResourceModifierActionWorker.removeSshFirewallRule` and the port-forward cleanup bound in `KubernetesClusterScaleWorker.scaleKubernetesClusterIsolatedNetworkRules`, with file/line references, full logs, and a concrete reproduction (3-step API sequence). This gives enough context for a focused fix plus regression test. | ### ๐ Similar issues No similar or duplicate open issues were found via search. <details><summary>๐ก Notes and suggestions</summary> - Root cause per reporter: the SSH rule selector in `removeSshFirewallRule` matches on `sourcePortStart == 2222` OR "any port-forward rule with destination port 22", which incorrectly also matches the first separate-etcd SSH rule (source port 50000, destination 22) when the control/worker rule was recreated after the etcd rules during scale-up. The subsequent cleanup then uses the wrongly-selected rule's end port as the upper bound, deleting forwards it shouldn't (2222โ50000 range). - Suggested fix direction (from reporter): distinguish control/worker SSH rules from separate-etcd SSH rules explicitly (e.g., by tagging or tracking rule purpose/type) rather than relying on port-number heuristics, and bound the port-forwarding cleanup to only the intended rule's range. - A regression test scenario is suggested: create a cluster with 3 separate etcd nodes, scale 1โ2โ1, and verify rule identities/ordering after recreation. - Reporter also notes the partial VM removal and stale cluster size (`size=2` reported with only 1 worker VM) after a network-rule failure should have recovery/rollback handling โ worth considering as part of the fix or as a follow-up. - Relevant files: `plugins/integrations/kubernetes-service/src/main/java/com/cloud/kubernetes/cluster/actionworkers/KubernetesClusterResourceModifierActionWorker.java` (lines ~546-558) and `KubernetesClusterScaleWorker.java` (lines ~134-155). </details> > Generated by [Daily Issue Triage](https://github.com/apache/cloudstack/actions/runs/34849890864) ยท sonnet50 90K ยท [โท](https://github.com/search?q=repo%3Aapache%2Fcloudstack+%22gh-aw-workflow-call-id%3A+apache%2Fcloudstack%2Fdaily-issue-triage%22&type=issues) > <details> <summary>Add this agentic workflows to your repo</summary> To install this agentic workflow, run ``` gh aw add githubnext/agentics/workflows/daily-issue-triage.md@d7c1dc4b72b00607a67caaffdcc216cb64379cf9 ``` </details> <!-- gh-aw-agentic-workflow: Daily Issue Triage, engine: copilot, version: 1.0.52, model: claude-sonnet-5, id: 34849890864, workflow_id: daily-issue-triage, run: https://github.com/apache/cloudstack/actions/runs/34849890864 --> <!-- gh-aw-workflow-call-id: apache/cloudstack/daily-issue-triage --> -- 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]
