This is the fix for only one particular, but important case.
The case when a new resource has been added to the chart and
there is an error in the chart, which leads to release failure.
In this case after first failed release upgrade new resource will be
created in the cluster. On the next release upgrade there will be the error:
`no RESOURCE with the name NAME found` for this newly created resource
from the previous release upgrade.
The root of this problem is in the side effect of the first release process,
Release invariant says: if resouce exists in the kubernetes cluster, then
it should exist in the release storage. But this invariant has been broken
by helm itself -- because helm created new resources as side effect and not
adopted them into release storage.
To maintain release invariant for such case during release upgrade operation
all newly *successfully* created resources will be deleted in the case
of an error in the subsequent resources update.
This behaviour will be enabled only when `--cleanup-on-fail` option used
for `helm upgrade` or `helm rollback`.
Signed-off-by: Timofey Kirillov <timofey.kirillov@flant.com>
* Refactor test run to separate method
This will allow us to parallelise it more easily
Signed-off-by: Frank Hamand <frankhamand@gmail.com>
* Add --parallel flag to helm test
(No functionality in this commit)
Signed-off-by: Frank Hamand <frankhamand@gmail.com>
* Run helm tests in parallel with --parallel flag
Signed-off-by: Frank Hamand <frankhamand@gmail.com>
* Add a mutex to helm test message streams
This is to protect against data races when running tests in parallel.
Signed-off-by: Frank Hamand <frankhamand@gmail.com>
* Add tests for --parallel flag
Signed-off-by: Frank Hamand <frankhamand@gmail.com>
* Add concurrency limit for parallel helm tests
Signed-off-by: Frank Hamand <frankhamand@gmail.com>
* Add test for concurrency limit
Signed-off-by: Frank Hamand <frankhamand@gmail.com>
* Fix rebase introduced errors
Signed-off-by: Frank Hamand <frankhamand@gmail.com>
When 'helm <install|upgrade> --render-subchart-notes ...' is run, this will include
the notes from the subchart when rendered via Tiller.
Closes#2751
Signed-off-by: jgleonard <jgleonard@gmail.com>
This adds support for installing CRDs well before any other resource
kinds are installed.
This PR introduces a new hook, `crd-install`, that fires before
manifests are even validated. It is used to install a CRD before any
other part of a chart is installed.
Currently, this hook is _only implemented for install_. That means we
currently cannot add new CRDs during `helm upgrade`, nor can they
be rolled back. This is the safest configuration, as the update/rollback
cycle gets very challenging when CRDs are added and removed.
Existing helm.sh/hook-delete-policy annotation variables (hook-failed, hook-succeeded) do not allow to leave failed jobs for debugging without blocking the next job launching: every failed job must be deleted manually before the next related release is launching (installing, updating or rolling back).
New policy, before-hook-creation, removes the hook from previous release if there is one before the new hook is launched and can be used with another variable.
Each maintainer can have an optional URL. There are seceral use
cases for providing a URL instead of an email address:
- The case where a maintainer wants to hide their email address
behind a webform for personal security
- When the maintainer is an organization and feedback should
go to an issue queue
This change:
- Adds the proto field for url
- Updates the generated files for the chart proto
- Includes linting for the url
- Updates the docs to include the url
Closes#3056
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
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.
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.
This feature adds the ability to selectively control the loading of charts using entries in top chart's values.
When 'helm install --set tags.mytag=true', charts with that tag will be enabled unless disabled in parent by condition.
When 'helm install --set mychart.enabled=true', charts with that yaml path specified will be enabled.
Closes#1837
Jeff Knurek