kiranchavala opened a new issue, #14491:
URL: https://github.com/apache/cloudstack/issues/14491
### problem
In a zone that has clusters of more than one hypervisor type (e.g. KVM,
VMware and XenServer), creating a CKS cluster for one of them (e.g. KVM, using
a KVM template and/or `hypervisor=KVM`) puts the node VMs on the KVM cluster.
The isolated network's virtual router, however, ends up on the VMware or
XenServer cluster.
### versions
- Apache CloudStack: 4.21.x, 4.22.x 4.23.x
- Hypervisors: KVM, VMware, XenServer clusters in the same zone
- Network: isolated network created by CKS (VirtualRouter provider)
### The steps to reproduce the bug
1. Create an advanced zone with three clusters: KVM, VMware and XenServer.
Register system VM templates for all three, and leave
`system.vm.default.hypervisor` to ANY
2. Register a Kubernetes ISO
3. Create a CKS cluster with `hypervisor=KVM`, without passing an existing
network, so CKS creates a new isolated network.
4. Check where the router is running (`listRouters networkid=<cks network>`)
and where the node VMs are running.
**Root cause**
`KubernetesClusterStartWorker.startKubernetesClusterOnCreate()` starts the
cluster network before any node VM is deployed:
```java
Map<String, DeployDestination> destinationMap =
planKubernetesCluster(domainId, accountId, clusterTemplate.getHypervisorType(),
clusterTemplate.getArch());
dest = destinationMap.get(WORKER.name());
...
networkMgr.startNetwork(network.getId(), destination, context);
```
`KubernetesClusterResourceModifierActionWorker.plan()` finds a suitable host
of the correct hypervisor type. It then drops that information and returns a
destination containing only the zone:
```java
if (useDedicatedHosts) {
return new DeployDestination(zone, null, null, suitableHost);
}
return new DeployDestination(zone, null, null, null);
```
When the router is deployed, `NetworkHelperImpl.getHypervisors()` adds the
cluster's hypervisor only when `dest.getCluster() != null`. With no cluster and
no default system VM hypervisor configured, it uses
`getSupportedHypervisorTypes(zone)`, which is every hypervisor type in the
zone. `deployRouter()` then uses the first type in that list that has a system
VM template, which can be VMware or XenServer.
In a normal VM deployment this doesn't happen.
`VirtualMachineManagerImpl.orchestrateStart()` runs the deployment planner
first, so the destination it passes to `NetworkOrchestrator.prepare()` /
`implementNetwork()` includes pod, cluster and host. The router therefore gets
the VM's hypervisor type.
`KubernetesClusterResourceModifierActionWorker.plan()` has returned a
destination without a cluster since CKS was introduced. Since 4.21, the
`hypervisor` parameter on `createKubernetesCluster` lets the nodes go on a
chosen hypervisor in a mixed zone. The virtual router still doesn't follow that
choice.
Expected
The virtual router is deployed on the same hypervisor type as the CKS nodes
(KVM).
Actual
The CKS node VMs are on the KVM cluster, but the virtual router is on the
VMware or XenServer cluster.
### What to do about it?
Pass the cluster of the selected host in the `DeployDestination` that
`KubernetesClusterResourceModifierActionWorker.plan()` returns, as
`KubernetesClusterManagerImpl.plan()` already does:
```java
ClusterVO planCluster = clusterDao.findById(suitableHost.getClusterId());
if (useDedicatedHosts) {
return new DeployDestination(zone, null, planCluster, suitableHost);
}
return new DeployDestination(zone, null, planCluster, null);
```
The router then gets the node cluster's hypervisor type, the same as in a
normal VM deployment.
--
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]
