When using `helm upgrade --install`, if the first release fails, Helm will respond with an error saying that it cannot upgrade from an unknown state.
With this feature, `helm upgrade --install --force` automates the same process as `helm delete && helm install --replace`. It will mark the previous release as DELETED, delete any existing resources inside Kubernetes, then replace it as if it was a fresh install. It will then mark the FAILED release as SUPERSEDED.
Fixes#2437
Two bugs were causing this behavior
- Tiller was marking the previous release superseded when an upgrade
failed.
- Upgrade was diffing against failed releases
When release upgrade fails, updatedRelease is already created
in a storage by *ReleaseServer.UpdateRelease, therefore we should
be updating it's status, not creating it again.
Tiller currently hangs indefinitely when deadlocks arise from certain
concurrent operations. This commit removes the nested mutex locking
system from pkg/Storage and relies on resource contention controls in k8s.
Closes#2560
* give an uniform check for release process
* fixed as the review of adamreese: update the err message when releasename is empty and update the test units.
* fixed as the review of bacongobbler: add more detail information to return message. the regex rule is added to the return message.
This builds on previous work and adds more logging to follow
the full process of installing, updating, deleting, and rolling back.
This also standardizes capitalization of logs and small formatting
fixes
Michelle Noorali
Matthew Fisher
Adam Reese
Maxim Ivanov
Matt Butcher
Justin Scott
Aishwarya Thangappa
Y.W
Taylor Thomas
fibonacci1729