This reverts commit d2ab3f5062.
The reverted commit turned out to be a workaroud another problem.
The real fix is submitted in PR #5680
Signed-off-by: Marc Khouzam <marc.khouzam@ville.montreal.qc.ca>
- Add ability to test for nested non-existent keys
- Add test cases for nested null values
- Minimalist fix for nested null key test cases
- Add missing metadata to integration test
Signed-off-by: Adam Eijdenberg <adam.eijdenberg@digital.gov.au>
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)
Flags sometimes can be used with an = sign, such as --kube-context=prod.
In this case, the variable ${flagname} retains the = sign as part of the
flag name. However, in zsh completion, an = sign cannot be part of an
index of the associative array 'flaghash' or else it causes an error.
This commits strips the = sign out when using ${flagname} as an index.
Note that this is not a big deal since flaghash is not actually used
anywhere in Helm completion. I believe it is made available by the
Cobra framework in case some completions choose to use it.
Signed-off-by: Marc Khouzam <marc.khouzam@ville.montreal.qc.ca>
As many people have requested and discussed in #3159.
The variable name are kept the same as before. Corresponding command-line flag is named, and description are written, after the existing flag for gRPC.
The scope of this change is intentionally limited to the minimum. That is, I have not yet added `--probe=false`, because it shouldn't be a blocker if we can change the port number.
Signed-off-by: Yusuke KUOKA <ykuoka@gmail.com>
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>
Deepak Sattiraju
Matthew Fisher
Marc Khouzam
Xiang Dai
Martin Hickey
Adam Eijdenberg
dev-chulbuji
Tariq Ibrahim
Jon Huhn
Morten Torkildsen
Jeff Knurek
Matt Farina
Luis Davim
Étienne Lafarge
Evan Vetere
SataQiu
xichengliudui
Timofey Kirillov
Taylor Thomas
Yusuke KUOKA
Joschka Tillmanns
Xiangxuan Liu
Mike Eves
tariqibrahim