Add annotation handling of new annotation helm.sh/update-policy with values recreate-on-conflict and recreate-on-invalid values to better deal with the following cases.
The server responds with 'invalid' e.g. if a certain resource contains an immutable field, which cannot be patched or updated by a PUT. In theses cases it can be helpful to delete the resource and recreate it. Examples for theses cases are:
* roleRef in RoleBinding
* spec.clusterIP in Service
* parameters in StorageClass
If a chart developer has made sure that recreating a resource is safe, the annotation can be added to a resource template. Alternatively a user may add the annotation manually to an existing resource to allow Helm to recreate a certain resource.
Adding the new annotation in general by default or changing the default behaviour of Helm is not a good idea, since deletion and recreation of certain resources can lead to an unwanted or undefined state as described in detail in https://github.com/helm/helm/pull/7431#issuecomment-666735299:
"[...] selectively deleting/re-creating volume-backed resources (Secrets, Services, ConfigMaps, PVCs) without touching the Deployment. If a Persistent Volume Claim is deleted and re-created, there is a risk that an application (Deployment) consuming that Persistent Volume Claim will not receive the new volume's mount point. The same can be said for Secrets, Configmaps, Services, and other resources which are deployed and relied upon by another resource. Environment variables populated in a Deployment from a Service won't be updated until the Pods are destroyed."
Closes#7082.
Signed-off-by: Daniel Strobusch <1847260+dastrobu@users.noreply.github.com>
This reverts commit 4a27baaffc.
Note, PR #11129 was layered in along with this change so the revert
preserves this API addition.
Signed-off-by: Matt Farina <matt.farina@suse.com>
The ordering should be:
1. User specified values (e.g CLI)
2. Parent chart values
3. Imported values
4. Sub-chart values
This enables parnet charts to import large set of values from a
child and then override select values.
This change is needed for backwards compatibility.
Fixes#12460
Signed-off-by: Matt Farina <matt.farina@suse.com>
As described in issue #12432 (https://github.com/helm/helm/issues/12432) the default serviceaccount yaml will be created wrong. This commit will fix this.
Signed-off-by: Lars Zimmermann <info@zimmermann-lars.de>
The assumption that either a username and/or password OR an error is
returned appears to be wrong, and results in an error later on which
looks something like the following:
```
failed to authorize: failed to fetch anonymous token: unexpected status
from GET request to https://auth.docker.io/token?scope=repository%3AXXX%2FYYY%3Apull&service=registry.docker.io:
401 Unauthorized
```
To mitigate this, confirm we actually have one of the values before
setting the `Authorization` header.
Co-authored-by: Joe Julian <me@joejulian.name>
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
Helm release names are limited to 53 characters. By default, Release information is stored in Kubernetes as secrets, and the secret's name structure follows the pattern "sh.helm.release.v1.<release name up to 53 characters>.v<release revision>." However, in the case of using an SQL backend, this release information key is stored in the release_v1 table, and the table constraint currently limits the key name length to 67 characters. This limitation may not be suitable for release names that are within Helm's 53-character limit and need to accommodate the additional "sh.helm.release.v1." prefix and the release revision suffix.
Signed-off-by: abrarcv170 <78675575+abrarcv170@users.noreply.github.com>
Daniel Strobusch
Sean Mills
Matt Farina
Scott Rigby
Marcin Chojnacki
Matt Farina
Dmitry Chepurovskiy
genofire
b4nks
Lars Zimmermann
Hidde Beydals
Michał Słapek
abrarcv170
Joe Julian
Maxim Trofimov
Tim Chaplin
Bingtan Lu
ithrael
0xff-dev