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.
When "helm.sh/hook-delete-policy: hook-succeeded" is provided in a hook's annotation, Tiller will automatically delete the hook after the hook is succeeded. When "helm.sh/hook-delete-policy: hook-failed" is provided in a hook's annotation, Tiller will automatically delete the hook after the hook is failed.
Closes#1769
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.
For some reason, GetReleaseContent was configured to return the latest
release only if it is in state DEPLOYED. But a release with a version is
returned regardless of release. This made it really hard to debug failed
releases, even though we have the data to show.
Closes#2525
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
Extracted delete specific code from ReleaseServer to external function
which is called from both Local and Remote ReleaseModules.
Made getVersionSet function from tiller package exported.
This change introduces the concept of Rudders - pluggable modules that
Tiller communicates with via grpc, which allow to decouple orchestration
logic from Tiller into separate service.
This commit consists of simple Rudder implementation which does exactly
the same thing as built in Tiller orchestrator - it creates all k8s
objects from provided manifest without orchestrating them.
--experimental-release flag is introduced to enable this behaviour.
This change allows to use the service and tiller outside of the cluster.
Following commits will add Rudder to helm deployment.
Adds an `unreleased` flag to the version if not building from HEAD of a
tag. The compatibility check is bypassed if the client or server are
unreleased.
fixes#2110
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.
It is now possible to create plugins with chart download capabilities for custom, non-http protocols.
Furthermore it is possible to reuse helm packages to implement alternative clients with these custom downloader functions.
This provides the Chart.yaml field `tillerVersion`, which is a semver
range. It allows users to choose to constrain a chart to a specific
version.
The reason for this is that we keep introducing new template functions,
but we have no way of saying "this chart will only work with Tiller
newer than...".
The check on version is _only_ done on Tiller. The client does not check
at all, since it does not do any template expansion on its own.
The following kinds are newly addressed:
CronJob
LimitRange
ReplicaSet
ResourceQuota
StatefulSet
Furthermore, adjust the installation and uninstallation order to
better respect likely dependencies. Bare pods remain a difficult one
to place properly in both sequences.
During installation and uninstallation, handle the RBAC-related
ClusterRole, ClusterRoleBinding, Role, and RoleBinding kinds in an
order that respects their potential referential integrity, namely that
ClusterRoleBindings can refer to ClusterRoles and ServiceAccounts, and
RoleBindings can refer to ClusterRoles, Roles, and ServiceAccounts.
Fixes#2199.
closes#2136
* Adds new annotation `helm.sh/hookWeight`
* Sorts executing hooks of similar kind in ascending order
* There is no upper or lower bounds on the weights
Most newcomers hit helm's 'feature' there deleted instalations are not really deleted.
Use-case
# helm install --name gitlab-ce-1 ./stable/gitlab-ce
# helm delete gitlab-ce-1
# helm list
# helm install --name gitlab-ce-1 ./stable/gitlab-ce
Error: a release named "gitlab-ce-1" already exists
There is a lot duplicated bugs in bugzilla which simply explains that packages
should be deleted with --pure flag. But such bugs appeared again and again
because this behavior is not obvious.
Let's help user to figure out what happens ASAP.
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