Closes#6751
After doing some more digging, I found out that updating the status
of an `Ingress` object is completely optional. Because of this, Helm
cannot support ingresses with the `--wait` flag because there is no
standard way to identify that they are ready
Signed-off-by: Taylor Thomas <taylor.thomas@microsoft.com>
.Get() calls perform() on a list of infos, populating two shared maps. perform() now concurrently calls the ResourceActorFunc concurrently based on GVK, causing a data race condition in .Get()
This fixes that condition by locking the function to ensure these functions run serially for Helm 2 to fix the data race condition. This has since been optimized in Helm 3 so it's no longer an issue.
Signed-off-by: Matthew Fisher <matt.fisher@microsoft.com>
When waiting for resources use the `ListWatchUntil` instead of
`UntilWithoutRetry` so that if the connection drops between tiller and
the API while waiting the operation can still succeed.
Signed-off-by: Richard Connon <richard.connon@oracle.com>
Probably since K8s 1.13.x, `converter.ConvertToVersion(info.Object, groupVersioner)` which is the body of `asVersioned` doesn't return an error or an "unstructured" object, but `apiextensions/v1beta1.CustomResourceDefinition`.
The result was `helm upgrade` with any changes in CRD consistently failing.
This fixes that by adding an additional case of the conversion result being `v1beta1.CustomResourceDefinition`.
This is a backward-compatible change as it doesn't remove existing switch cases for older K8s versions.
Fixes#5853
Signed-off-by: Yusuke Kuoka <ykuoka@gmail.com>
Manifest validation is done by the builder, but it requires that the schema is set before the Stream function is called. Otherwise the StreamVisitor is created without a schema and no validation is done.
Signed-off-by: Morten Torkildsen <mortent@google.com>
Makes sure CRDs installed through the crd_install hook reaches the `established` state before the hook is considered complete.
Signed-off-by: Morten Torkildsen <mortent@google.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>
Don't delete a resource on upgrade if it is annotated with
helm.io/resource-policy=keep. This can cause data loss for users if the
annotation is ignored (e.g. for a PVC).
Closes#3673
Signed-off-by: James Ravn <james@r-vn.org>
Adam Reese
Taylor Thomas
Matthew Fisher
Jeff Knurek
Charlie Getzen
Richard Connon
Sakura
Yusuke Kuoka
Tariq Ibrahim
Martin Hickey
Morten Torkildsen
Per Hermansson
dev-chulbuji
xichengliudui
Timofey Kirillov
Pavel Eremeev
Fernando Barbosa
Jacob LeGrone
ds-ms
Michelle Noorali
Elad Iwanir
Ian Howell
James Ravn
Taylor Thomas
tariqibrahim