What happened: I updated the image of my deployment, but left off the --record option for which I had gotten a deprecated warning on the previous set image command. To my surprise, rollout history was showing the CHANGE-CAUSE not as blank, nor as the current image version, but as the previous image version! Note that the correct version is returned by get/describe commands, and rollout undo deployment also works correctly with the appropriate revision number i.e. it does NOT correspond to the incorrect image version included in the CHANGE-CAUSE against that revision number; there is no functional issue, this appears to be a simple bad text issue, which can nevertheless be confusing.
What you expected to happen:
I would expect rollout history to either show the current version (as shown via get or describe commands), or blank - but not with the incorrect version.
How to reproduce it (as minimally and precisely as possible):
kubectl create deployment test-bug --image=nginx:1.20.2 --port=80 --replicas=2
kubectl set image deployment/test-bug nginx=nginx:1.21.5 --record
kubectl set image deployment/test-bug nginx=nginx:1.31.3
kubectl rollout history deployment/test-bug
REVISION CHANGE-CAUSE
1 <none>
2 kubectl.exe set image deployment/test-bug nginx=nginx:1.21.5 --record=true
3 kubectl.exe set image deployment/test-bug nginx=nginx:1.21.5 --record=true
Anything else we need to know?:
Issue originally encountered with kubectl client v1.35.1, packaged with minikube
Environment:
- Kubernetes client and server versions (use
kubectl version):
Client Version: v1.36.3
Kustomize Version: v5.8.1
Server Version: v1.35.1
- Cloud provider or hardware configuration:
Cloud provider: None (local Minikube using the VirtualBox driver)
Hardware: VirtualBox VM running on a local machine
- OS (e.g:
cat /etc/os-release):
wmic os get Caption, Version, BuildNumber, OSArchitecture
BuildNumber Caption OSArchitecture Version
19045 Microsoft Windows 10 Pro 64-bit 10.0.19045
What happened: I updated the image of my deployment, but left off the --record option for which I had gotten a deprecated warning on the previous set image command. To my surprise, rollout history was showing the CHANGE-CAUSE not as blank, nor as the current image version, but as the previous image version! Note that the correct version is returned by get/describe commands, and rollout undo deployment also works correctly with the appropriate revision number i.e. it does NOT correspond to the incorrect image version included in the CHANGE-CAUSE against that revision number; there is no functional issue, this appears to be a simple bad text issue, which can nevertheless be confusing.
What you expected to happen:
I would expect rollout history to either show the current version (as shown via get or describe commands), or blank - but not with the incorrect version.
How to reproduce it (as minimally and precisely as possible):
kubectl create deployment test-bug --image=nginx:1.20.2 --port=80 --replicas=2
kubectl set image deployment/test-bug nginx=nginx:1.21.5 --record
kubectl set image deployment/test-bug nginx=nginx:1.31.3
kubectl rollout history deployment/test-bug
REVISION CHANGE-CAUSE
1 <none>
2 kubectl.exe set image deployment/test-bug nginx=nginx:1.21.5 --record=true
3 kubectl.exe set image deployment/test-bug nginx=nginx:1.21.5 --record=true
Anything else we need to know?:
Issue originally encountered with kubectl client v1.35.1, packaged with minikube
Environment:
kubectl version):Client Version: v1.36.3
Kustomize Version: v5.8.1
Server Version: v1.35.1
Cloud provider: None (local Minikube using the VirtualBox driver)
Hardware: VirtualBox VM running on a local machine
cat /etc/os-release):