For some reason, many users experince corrupted storage with the
ConfigMaps storage backend. Specifically, several Releases are 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.
Closes#6031
Signed-off-by: Cristian Klein <cristian.klein@elastisys.com>
This commits adds the possibility to back Tiller (or the future
Tiller-less Helm CLI) with any SQL database (only postgres has been
tested so far) to store release information.
The main motivation for this commit was to use a storage backend that
would allow releases larger that 1MB in size (ConfigMap or Secret
drivers don't, because of limits on value size in the underlying etcd
key-value store).
Signed-off-by: Étienne Lafarge <etienne.lafarge@gmail.com>
Co-authored-by: Elliot Maincourt <e.maincourt@gmail.com> (@emaincourt)
Co-authored-by: Paul Borensztein <hi@0x01.fr> (@commit-master)
Solves #3722 by making the changes in #3539 more compatible with the previous behavior.
This gives a recovery option for "oops I deleted my helm release" by allowing rollback, which is intended to be a working feature of helm. Note that purging releases removes the history required to rollback, so this doesn't work in that case. However, purging takes significantly more time, so it's harder to accidentally purge everything.
Signed-off-by: Brent <bmperrea@gmail.com>
* Avoid importing k8s.io/kubernetes from pkg/helm
When writing a helm client (e.g. a helm plugin) that talks to tiller importing k8s.io/helm/pkg/helm to get the grpc client is key.
This pkg should not have a dependency to the k8s.io/kubernetes to avoid pulling in a lot of code that is only used within tiller and blow up binary sizes.
Signed-off-by: Fabian Ruff <fabian@progra.de>
* Add references to pull request in errors message
Signed-off-by: Fabian Ruff <fabian@progra.de>
* copy helper function from pkg/storage/driver
Signed-off-by: Fabian Ruff <fabian@progra.de>
* Move storage errors to seperate package
Signed-off-by: Fabian Ruff <fabian@progra.de>
* Keep old error variables for backward compatibility
Signed-off-by: Fabian Ruff <fabian@progra.de>
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.
Users can now specify a namespace filter for 'helm list'. Only the
releases within the specified namespace will be shown. For example,
'helm list --namespace foo' will only show releases for the 'foo'
namespace. Also added a namespace field to the table view.
Closes#1563
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
This commit changes the configmap storage driver to compress
the serialized release before storing it as a base64 encoded string.
This change is backward compatible as it handles existing releases
gracefully by skipping the decompression step when the gzip magic
header is not present.
Cristian Klein