github-actions[bot] commented on issue #14412: URL: https://github.com/apache/cloudstack/issues/14412#issuecomment-6216744189
## ๐ฏ Triage report The reporter observes that CKS cluster VMs provisioned with a "shared network" do not get the expected Security Group applied, preventing the management server from reaching the Kubernetes API (port 6443) and thus from fetching `kube.conf`. Manually attaching the Security Group fails because CloudStack requires the VM to be stopped before updating security groups on a running instance โ which is a known general platform constraint, not specific to CKS. ### ๐ Assessment | Dimension | Value | Reasoning | |---|---|---| | **Type** | `type:bug` | CKS provisioning should apply the configured Security Group to created VMs; it appears not to for shared-network deployments. | | **Component** | `component:kubernetes`, `component:security-group` | Affects CKS cluster VM provisioning and Security Group assignment. | | **Severity** | n/a | Insufficient detail to assess severity/impact scope (e.g., whether this reproduces consistently, zone/network configuration specifics). | | **Labels** | type:bug, component:kubernetes, component:security-group | See above | | **Coding agent** | Not suitable | Requires investigation into CKS provisioning logic for shared networks, and a design decision on whether/how to allow security group updates on running VMs or ensure SG assignment at creation time; not self-contained. | ### ๐ Similar issues - https://github.com/apache/cloudstack/issues/5999 (related) โ CKS cluster getting stuck in "Starting" mode, a different but adjacent CKS provisioning issue. <details><summary>๐ก Notes and suggestions</summary> - Missing details that would help: exact steps to create the CKS cluster (API/UI), the shared network configuration (advanced zone, VLAN/can-share settings), whether the Security Group is specified in the CKS cluster creation API call, and CloudStack management server logs during cluster VM provisioning. - Worth checking: does `createKubernetesCluster` (or VM deployment within CKS) pass `securitygroupids` through to `deployVirtualMachine` when a shared network is used? Compare with Isolated/CKS network flow mentioned by the reporter as working correctly. - The "VM must be stopped to update security groups" behavior is a long-standing platform constraint (`UserVmManagerImpl`) and is likely working as intended; the actionable bug here is why the SG isn't applied at creation time for shared-network CKS deployments. </details> > Generated by [Daily Issue Triage](https://github.com/apache/cloudstack/actions/runs/38908853463) ยท sonnet50 107.4K ยท [โท](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: 38908853463, workflow_id: daily-issue-triage, run: https://github.com/apache/cloudstack/actions/runs/38908853463 --> <!-- 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]
