Fixed old releases rotation procedure to not require a deployed release to exists.
An error will arise when there are no successfully deployed release yet, but releases history limit has been reached. In such situation helm will refuse to upgrade release anymore with "... has no deployed releases" error.
Furthermore, release rotation procedure already expecting lastDeployedRelease to be either nil, or not nil. So it is assumed that deployed release may exist or may not and these both outcomes were already expected as a valid situation rather than a failure.
Reworked storage_test.go TestStorageRemoveLeastRecentWithError test case: use mocked driver and test release creation procedure does not shadows errors from the underneath release rotation procedure.
Signed-off-by: Timofey Kirillov <timofey.kirillov@flant.com>
Previously, storage.Create was ignoring the error. This meant that a user that
relied on the recent release version cleanup would not be notified if that
cleanup failed, and release versions could grow without bound.
Closes#9145
Signed-off-by: Daniel Lipovetsky <dlipovetsky@d2iq.com>
Helm does not yet properly handle concurrent executions (see #7322),
and invoking Helm concurrently on the same release lead to corrupted storage.
Specifically, several Releases may be marked as DEPLOYED. This patch improved handling of such situations, by taking the latest
DEPLOYED Release. Eventually, the storage will clean itself out, after
the corrupted Releases are deleted due to --history-max.
This is a port to Helm v3 of #7319.
Signed-off-by: Cristian Klein <cristian.klein@elastisys.com>
The error returned from DeployedAll will never contain "not found".
The error returned at the end of Deployed is already known to be nil,
and we never want to return ls[0] together with a non-nil error anyway.
Signed-off-by: Simon Alling <alling.simon@gmail.com>
* Change release storage name to prefix helm storage type
Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
* Add comments about the Kubernetes storage object type field content
Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
To match the convention of `helm install`, `helm uninstall` is the inverse.
Other tangential changes in this PR:
- StatusDeleting has been changed to StatusUninstalling
- StatusDeleted has been changed to StatusUninstalled
- `helm list --deleted` has been changed to `helm list --uninstalled`
- `helm list --deleting` has been changed to `helm list --uninstalling`
- `helm.DeleteOption` and all delete options have been renamed to `helm.UninstallOption`
I have not made any changes to the "helm.sh/hook-delete-policy", "pre-delete" and "post-delete" hook annotations because
1. it's a major breaking change to existing helm charts, which we've commited to NOT break in Helm 3
2. there is no "helm.sh/hook-install-policy" to pair with "helm.sh/hook-uninstall-policy", so delete still makes sense here
`helm delete` and `helm del` have been added as aliases to `helm uninstall`, so `helm delete` and `helm del` still works as is.
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.
* add test for rolling back from a FAILED deployment
* Update naming of release variables
Use same naming as the rest of the file.
* Update rollback test
- Add logging
- Verify other release names not changed
* fix(tiller): Supersede multiple deployments
There are cases when multiple revisions of a release has been
marked with DEPLOYED status. This makes sure any previous deployment
will be set to SUPERSEDED when doing rollbacks.
Closes#2941#3513#3275
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
This adds a new configuration option to Tiller to limit the number of
records stored per release.
Tiller stores historical release information (helm history, helm
rollback). This makes it possible to set a maximum number of versions
per release.
To enable this feature, use `helm init --history-max NNN`. Note that
because of the restrictions on Deployment objects, you will have to
re-install Tiller to add a limit.
Along the way, I found an unreported bug in the Memory storage driver.
This fixes that bug and adds substantially more tests to catch
regressions.
Closes#2332
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
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
Environment is supplied with release lock map which allows to lock a
release by name to make sure that update, rollback or uninstall aren't
running on one release at the same time.
There are some places where releases are only located if they are in the
state DEPLOYED. That particular logic was incorrectly used for upgrades.
That caused #1566. While fixing that issue, I found that this was also
the root cause of #1587 (though because it was off by one). I added a
generic method to get the last release, regardless of its status.
This allows some behaviors that previously failed:
- 'helm upgrade' can now be performed on a DELETED release
- 'helm rollback' can now be performed on a DELETED release even if
there is only one revision of that release history.
Closes#1566Closes#1587
