The files contained in the `tar` file from `helm package` did not have
the correct timestamp. This lack of timestamp occurred because we were
not writing any time to the tar header file.
Address a race condition that arises when running two `helm install`
commands, both of which specify a namespace that does not already exist.
In this specific instance, attempting to create a `namespace` which
already exists shouldn't be a failure which causes `helm install` to
terminate.
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.
The choice of interface `--output (json|yaml)` is to match that of the
status command, except that -o is not available as it is already used
by --offset.
WIP #1534
`toYaml` was introducing a new line. It is an issue since the new line is part of a functions output, it can't be whitespace chomped away so it would require a `trimSuffix "\n"` pipe. This commit trims one trailing `\n` from the toYaml output.
`toYaml` utilized by `.Files` was introducing a new line. It is an issue since the new line is part of a functions output, it can't be whitespace chomped away so it would require a `trimSuffix "\n"` pipe. This commit trims one trailing `\n` from the toYaml output.
Resolves#3655
We were seeing that when running helm upgrade with the reuse-values
flag enabled that you could end up in the position where overrides
a.k.a computed values from previous revisions were not being saved on
the updated revision. This left us in a weird position where some
computed values would disappear mysteriously in the abyss. That
happened because computed values from previous revisions weren't merged
with the new computed values every time the reuse-values flag was used.
This PR merges computed values from the previous revisions so you don't
end up in that kind of conundrum.
* fix(helm): fix golint warning due to ApiVersionV1 constant name
Signed-off-by: Arash Deshmeh <adeshmeh@ca.ibm.com>
* fix(helm): fix golint warning due to ResolveChartVersionAndGetRepo comment
Signed-off-by: Arash Deshmeh <adeshmeh@ca.ibm.com>
* fix(helm): fix golint warnings on HttpGetter type and SetCredentials method missing a comment
Signed-off-by: Arash Deshmeh <adeshmeh@ca.ibm.com>
* fix(helm):fix golint warning due to comment on FindChartInAuthRepoURL function
Signed-off-by: Arash Deshmeh <adeshmeh@ca.ibm.com>
* fix(helm): fix golint warning due to RepoFile type name
Signed-off-by: Arash Deshmeh <adeshmeh@ca.ibm.com>
* fix(helm): fix golint warning due to ParseString comment
Signed-off-by: Arash Deshmeh <adeshmeh@ca.ibm.com>
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.
When Helm v2.8.2 was released, we made a change to the default connection timeout by supplying a value passed from pkg/helm/environment. This broke support for third party clients relying on pkg/helm because now the default connection timeout is zero. Adding a default 5 second timeout back retains old behaviour, while not breaking backwards compatibility because the connection timeout can still be configured.
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
Between grpc 1.2.x and 1.7.x there was an API change. The
previous MaxMsgSize is now a wrapper around MaxRecvMsgSize. This
change now sets the MaxRecvMsgSize and MaxSendMsgSize which need
to be set independently.
CRDs and other objects seen as unstructured cannot use strategic
merge patching. It has never been supported on CRDs. Previously,
cases like unstructured objects could have caused an unregistered
error. This is no longer the case.
This change explicitly looks for unstructured objects and handles
those using json merge patching.
Closes#3382
Prior to this, using the semver template functions with the full
version, which is represented in the GitVersion, was not possible
for helm template and lint commands because the property was not
populated by default. This update adds default handling.
Closes#3349
* Add template for chart name
* Use named ports and simplify service configuration
* Add affinity
* Add tolerations
* Use 'with' statements where possible
* Enhance ingress
* Add fullnameOverride to fullname template
When a user enters a non-URL (such as stable)
in requirements.yaml and tries to `helm dep up`,
they get a potentially confusing error message.
This tries to make the error message clearer.
Closes#2672
This error occures when resource is not found in helm release:
`Error: UPGRADE FAILED: no resource with the name "redis-cluster-sentinel" found`
Changed to:
`Error: UPGRADE FAILED: no ConfigMap with the name "redis-cluster-sentinel" found`
So now that resource can easily be found in cluster.
change to helm client to no longer save request options in the client
options. This resulted in options from a previous call still being
present in future calls.
Closes#3253
* Add "--namespace" to helm lint
Keep lint syntax as close as possible to "helm install" resp. "helm
upgrade", so that one only needs to change the command.
See #2036
* Align lintCmd struct
* Add "--set" and "--values" to helm lint
Keep lint syntax as close as possible to "helm install" resp. "helm
upgrade", so that one only needs to change the command.
Closes #2495,#2036
* Reuse strict parameter, when rendering during lint
We want to see the rendering fail, if we missed a value, so we reuse
"--strict".
See #2495,#2036
* Fix lint unit test
See #2495,#2036
* Update docs
New users to helm don't always run `helm init` (e.g. if their cluster
already has helm installed). The user's initial interaction with any of
helm's repository commands (e.g. `helm repo list`) will then be an error
message due to a missing repositories.yaml in their local config.
Give the user a little hint about how to fix the error without them having
to hunt through the man/help pages.
k8s client-go closes the ready channel that's passed in (see https://github.com/kubernetes/client-go/blob/master/tools/portforward/portforward.go#L171) This means that Tunnel's Close will always panic, as the client-go library will have closed then channel. This isn't reproducible unless helm.Client is externally, as the helm cli runner doesn't actually invoke Close.
Adding a user-agent to the http getter will enable servers to
distinguish between helm (including various versions) and other
tools connecting to the server.
* fix(helm): add TLS params back
During a recent refactor, several TLS flags stopped being processed for
a few of the commands. This fixes those commands, and documents how to
set up TLS.
* fix(tiller): add stricter certificate verification
The older version of Tiller allowed a weaker set of certificate checks
than we intended. This version requires a client certificate, and then
requires that that certificate be signed by a known CA. This works
around the situation where a user could provide a self-signed
certificate.
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
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