Unfortunately errors from the API server do not always (do they ever?) contain
the name of the resource in question.
Deletions for multiple resources are processed concurrently, so in a resulting
log, a preceding "Starting delete" line might be for a different object.
Signed-off-by: Marcin Owsiany <porridge@redhat.com>
This required modifying the `kube.Factory` interface to conform to
changes in k8s' `cmdutil.Factory` interface:
fe3772890f
Signed-off-by: Andrew Seigner <andrew@sig.gy>
If set, 'uninstall' command will wait until all the resources are deleted before returning.
It will wait for as long as --timeout
closes#2378
Signed-off-by: Mike Ng <ming@redhat.com>
managedFields were a changed that landed in 1.18. This is an array
under metadata with managedFields. The kubernetes client pkgs that
Helm uses automatically add them.
This change added a manager for the managedFields. The flow for
deciding on the name to use is:
1. An explicit name if one is chosen
2. The base name of the first os.Arg (the binary name) if no name
explicitly set.
3. unknown if no name set and name cannot be detected
The name is at the package level as there is no other place to easily
set it for Helm v3. Since the name is for the binary or app it should
be ok to set app wide.
Signed-off-by: Matt Farina <matt.farina@suse.com>
Since Tiller is no longer part of Helm v3, internal documentation
language about Tiller can be removed
Signed-off-by: Matt Farina <matt@mattfarina.com>
* Continue deleting objects when one fails to minimize the risk of an
upgrade ending in an unrecoverable state
* Exclude failed deleted object from the returned result set
Signed-off-by: Adam Reese <adam@reese.io>
Upgrade Kubernetes libraries to v0.18.0
Add new lazy load KubernetesClientSet to avoid missing kubeconfig error
In kubernetes v1.18 kubeconfig validation was added. Minikube and Kind
both remove kubeconfig when stopping clusters. This causes and error
when running any helm commands because we initialize the client before
executing the command.
Signed-off-by: Adam Reese <adam@reese.io>
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)
Close#7677
Signed-off-by: Dong Gang <dong.gang@daocloud.io>
Fixes issue #7279.
Prevent the deletion of CRDs that were defined in the `templates/`
directory. This makes CRD deletion behaviour consistent with Helm
documentation:
> CRDs are never deleted. Deleting a CRD automatically deletes all of the
> CRD’s contents across all namespaces in the cluster. Consequently, Helm
> will not delete CRDs.
Previous the documentation only applied to CRDs that were defined in the
`crds/` directory. It did not consider that Charts could have CRDs in the
`templates/` directory (for example charts that were written before the
`crds/` directory feature or if the Chart author needed templated CRDs).
Signed-off-by: Phil Grayson <phil@philgrayson.com>
* Port watcher with retries to wait for resources
Port of Helm 2 PR #6014 to Helm 3
Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
* Add fix from PR #6907
Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
Marcin Owsiany
Andrew Seigner
Martin Hickey
yxxhero
Matthew Fisher
Mike Ng
Matt Farina
小龙同学
Matt Farina
Cookie Wang
Joe Lanford
Jon Huhn
zh168654
Janario Oliveira
Rajat Jindal
Hidde Beydals
小明同学
Liu Ming
Adam Reese
Adam Reese
lnattrass
Dong Gang
ylvmw
Benn Linger
Matthew Fisher
Taylor Thomas
Jakub Bielecki
Ahmad Kazemi
Patrik Cyvoct
Phil Grayson
Adrian Gonzalez-Martin
Vibhav Bobade
Fabian Ruff
Charlie Getzen