bhouse-nexthop opened a new issue, #14629:
URL: https://github.com/apache/cloudstack/issues/14629
### problem
After a CKS cluster is upgraded, each upgraded node's Kubernetes version
(`kubernetes_cluster_vm_map.kubernetes_node_version`, shown as
`kubernetesnodeversion` in `listKubernetesClusters`) is stored as the raw
output of an SSH command: `v1.33.1\n`, with a `v` and a trailing newline. Nodes
created by the cluster's create or scale paths store `1.33.1`.
```
upgraded node: 76312E33332E310A ("v1.33.1\n")
scaled-up node: 312E33332E31 ("1.33.1")
```
Clients that print the field get a stray line break, and the two forms don't
compare equal.
Cause: `KubernetesClusterUtil.clusterNodeVersionMatches(...)` (the SSH
variant, used by `KubernetesClusterUpgradeWorker`) saves
`clusterVersionMatchesAndValue.second()`, which is the whole output of
```
sudo /opt/bin/kubectl get nodes | awk '{if ($1 == "<node>") print $5}'
```
That includes the newline, and anything the command wrote to stderr, such as
a `sudo` warning.
### versions
4.21.0.0 and later (since #9102), including 4.22 and main.
### The steps to reproduce the bug
1. Create a CKS cluster at one Kubernetes version.
2. Upgrade it to a newer version with `upgradeKubernetesCluster`.
3. `listKubernetesClusters id=<cluster>` and look at `kubernetesnodeversion`
for each VM, or `SELECT HEX(kubernetes_node_version) FROM
kubernetes_cluster_vm_map WHERE cluster_id = <id>`.
4. Upgraded nodes have `v<version>\n`; nodes added by a later scale-up have
`<version>`.
### What to do about it?
Once the node is found at the target version, record that version (the
semantic version of the upgrade), the same form the create path records.
--
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]
