kiranchavala opened a new pull request, #14492: URL: https://github.com/apache/cloudstack/pull/14492
### Description This PR fixes the CKS cluster network's virtual router being deployed on a different hypervisor (e.g. VMware/XenServer) than the Kubernetes nodes, in zones that have clusters of multiple hypervisor types. `KubernetesClusterStartWorker.startKubernetesClusterOnCreate()` starts the cluster's network before any node VM is deployed, using the `DeployDestination` returned by `KubernetesClusterResourceModifierActionWorker.plan()`. `plan()` finds a suitable host of the requested hypervisor type, but returned a destination with only the zone set: ```java return new DeployDestination(zone, null, null, null); ``` When implementing the network, `NetworkHelperImpl.getHypervisors()` only considers the destination cluster's hypervisor if `dest.getCluster() != null`. Without a cluster (and without `system.vm.default.hypervisor` set) it falls back to all hypervisor types in the zone, and the router is created with the first one that has a system VM template, which may not be the Kubernetes nodes' hypervisor. For a regular VM deployment the deployment planner runs first, so the destination passed to `implementNetwork()` contains the cluster and the router gets the VM's hypervisor type. With this change, `plan()` returns the cluster of the selected host in the `DeployDestination`, so CKS behaves the same way. **Expected:** the CKS network's virtual router is deployed on the same hypervisor type as the CKS nodes. **Actual (before fix):** the CKS nodes are deployed on the KVM cluster, but the virtual router is deployed on the VMware/XenServer cluster. Steps to reproduce: 1. Zone with KVM, VMware and XenServer clusters, system VM templates registered for all of them, `system.vm.default.hypervisor` unset. 2. Create a CKS cluster with a KVM template / `hypervisor=KVM` without passing a network. 3. `listRouters networkid=<cks network>` shows the router on a VMware/XenServer host. The issue is not observed when `system.vm.default.hypervisor` is set to the CKS nodes' hypervisor (e.g. KVM), because `getHypervisors()` adds the default hypervisor first and skips the zone-wide fallback. That workaround doesn't help zones that run CKS clusters on more than one hypervisor type. | `system.vm.default.hypervisor` | Router hypervisor candidates for a KVM CKS cluster, before | After | |---|---|---| | unset | all hypervisors in the zone (may pick VMware/XenServer) | `[KVM]` | | KVM | `[KVM]` | `[KVM]` | | VMware | `[VMware]` | `[VMware, KVM]` | Note: if `system.vm.default.hypervisor` (or the zone's `defaultSystemVMHypervisorType`) is set to another hypervisor, `NetworkHelperImpl.getHypervisors()` still tries it before the destination cluster's hypervisor. That is existing behaviour shared with regular VM deployments and is not changed here. Fixes: #14491 ### Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [x] Bug fix (non-breaking change which fixes an issue) - [ ] Enhancement (improves an existing feature and functionality) - [ ] Cleanup (Code refactoring and cleanup, that may add test cases) - [ ] Build/CI - [ ] Test (unit or integration test code) ### Feature/Enhancement Scale or Bug Severity #### Feature/Enhancement Scale - [ ] Major - [ ] Minor #### Bug Severity - [ ] BLOCKER - [ ] Critical - [x] Major - [ ] Minor - [ ] Trivial ### Screenshots (if appropriate): ### How Has This Been Tested? - Added unit test `KubernetesClusterResourceModifierActionWorkerTest#planTestDeployDestinationShouldContainClusterOfSuitableHost`, which checks that in a zone with KVM and VMware hosts, `plan()` for a KVM cluster returns a `DeployDestination` whose cluster is the KVM host's cluster. - Manual testing in a zone with mixed hypervisor clusters: pending. #### How did you try to break this feature and the system with this change? - Node VM placement is unchanged: in the non-dedicated case the destination from `plan()` is only used to start the network; in the dedicated-hosts case the host was already pinned and the added cluster is that host's cluster. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
