Assuming the following scenario:
$ helm install podinfo podinfo/podinfo
NAME: podinfo
LAST DEPLOYED: Fri Nov 10 15:07:18 2023
NAMESPACE: helm-system
STATUS: deployed
REVISION: 1
NOTES:
1. Get the application URL by running these commands:
echo "Visit http://127.0.0.1:8080 to use your application"
kubectl -n helm-system port-forward deploy/podinfo 8080:9898
$ helm upgrade podinfo podinfo/podinfo --set replicaCount=2 --set faults.unready=true --wait --timeout=10s
Error: UPGRADE FAILED: timed out waiting for the condition
$ helm uninstall podinfo --keep-history
release "podinfo" uninstalled
I would have expected the output from helm history to equal:
$ helm history podinfo
REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION
1 Fri Nov 10 15:07:18 2023 superseded podinfo-6.5.0 6.5.0 Install complete
2 Fri Nov 10 15:09:10 2023 uninstalled podinfo-6.5.0 6.5.0 Uninstallation complete
However, the actual output is:
$ helm history podinfo
REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION
1 Fri Nov 10 15:07:18 2023 deployed podinfo-6.5.0 6.5.0 Install complete
2 Fri Nov 10 15:09:10 2023 uninstalled podinfo-6.5.0 6.5.0 Uninstallation complete
Which actually can result in surprising behavior when performing a helm upgrade again with the --atomic flag set:
$ helm upgrade podinfo podinfo/podinfo --set replicaCount=2 --set faults.unready=true --wait --timeout=10s --atomic
Error: UPGRADE FAILED: release podinfo failed, and has been rolled back due to atomic being set: timed out waiting for the condition
$ helm history podinfo
REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION
1 Fri Nov 10 15:07:18 2023 superseded podinfo-6.5.0 6.5.0 Install complete
2 Fri Nov 10 15:09:10 2023 uninstalled podinfo-6.5.0 6.5.0 Uninstallation complete
3 Fri Nov 10 15:16:54 2023 failed podinfo-6.5.0 6.5.0 Upgrade "podinfo" failed: timed out waiting for the condition
4 Fri Nov 10 15:17:05 2023 deployed podinfo-6.5.0 6.5.0 Rollback to 1
I think this can either be solved by implementing a likewise fix as was done for helm rollback (see #2941), or by superseding deployed releases as soon as a mutation to the cluster has been made. Which seems to be more correct (and solving the issue at the root of the problem) in general.
Assuming the following scenario:
I would have expected the output from
helm historyto equal:However, the actual output is:
Which actually can result in surprising behavior when performing a
helm upgradeagain with the--atomicflag set:I think this can either be solved by implementing a likewise fix as was done for
helm rollback(see #2941), or by supersedingdeployedreleases as soon as a mutation to the cluster has been made. Which seems to be more correct (and solving the issue at the root of the problem) in general.