- Distinguish unowned resources from those whose ownership could not be
verified (e.g. RBAC/network errors). Unverifiable resources are now
returned in a separate list with the underlying error so log output
and the "kept" summary describe what actually happened.
- Only prefix the kept summary with the resource-policy header when
there are policy-kept resources, so users with only ownership-skipped
resources don't see a misleading header.
- Update verifyOwnershipBeforeDelete doc comment to reflect that
not-found resources are excluded from all returned lists.
- Assert success of Releases.Create in uninstall tests so fixture
setup failures are surfaced immediately.
Signed-off-by: Evans Mungai <mbuevans@gmail.com>
This commit adds ownership verification to the uninstall action. It checks that the resource to be deleted is owned by the chart before deleting it.
Fixes: #31333
Signed-off-by: Evans Mungai <mbuevans@gmail.com>
Fixes#31333
Helm uninstall now verifies resource ownership before deletion by checking
Helm labels and annotations. Resources not owned by the release being
uninstalled are skipped with warnings, preventing accidental deletion of
resources belonging to other releases.
Signed-off-by: Evans Mungai <mbuevans@gmail.com>
This ensures that when `helm uninstall` is run with `--keep-history`
any release in a `deployed` state other than the last release (e.g.
due to a failed upgrade) is being marked as `superseded`.
As a by-effect, running `helm upgrade` on a release which has been
uninstalled after an upgrade failure now no longer works. But instead
fails with a `"<name>" has no deployed releases` error. Which is the
(likely) intended behavior, and prevents other side-effects like
rolling back to a release version which happened before the uninstall
if `--atomic` (or `--rollback-on-failure`) was provided.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
The goal is to have the same behaviour with or without dry-run with --ignore-not-found
close#12970
Signed-off-by: Stephane Jeandeaux <stephane.jeandeaux@gmail.com>
This is part of HIP 20 which provides a means to have v3 charts
that live alongside v2 charts while having breaking changes.
The plan is to have a different release object for v3 chart
instances for at least a couple reasons:
1. So that the chart object on the release can be fundamentally
different.
2. So that Helm v3 does not detect or try to work with instances
of charts whose apiVersion it does not know about.
Note: it is expected that Helm v3 usage will be used long after
the Helm project no longer supports it. 5 years after Helm v2
had reached end-of-life there was still usage of it.
Note: The release util package is separate from the versioned
elements as it is planned to use generics to handle multiple
release object versions.
Signed-off-by: Matt Farina <matt.farina@suse.com>
This change moves the code, updates the import locations, and
adds a doc.go file to document what the v2 package is for.
This is part of HIP 20 for v3 charts
Signed-off-by: Matt Farina <matt.farina@suse.com>
The releaseutil package was originally designed to work against a
generated codebase from a protobuf in Helm v2. This is when Helm
used gRPC to communicate to a server side component named Tiller.
When Helm moved everything client side, this package remained and
it supported the release package.
This change moves releaseutil to be a sub-packge of release. This
is part of the change to support apiVersion v3 charts which is
documented in HIP 20
Signed-off-by: Matt Farina <matt.farina@suse.com>
chartutil was originally created to operate on protobufs which are
no longer part of Helm. The util package makes more sense to be
part of the chart package.
This change is part of the HIP 20 to create v3 charts and
explicitly call out v2 charts. The changes for this are in smaller
bite size changes.
Signed-off-by: Matt Farina <matt.farina@suse.com>
Since Helm is going through breaking changes with Helm v4, the version path to
Helm needs to be updated.
Signed-off-by: Matt Farina <matt.farina@suse.com>
Add --cascade=<background|foreground|orphan> option to helm uninstall
Current behaviour is hardcoded to background
Addresses issue: https://github.com/helm/helm/issues/10586
Signed-off-by: MichaelMorris <michael.morris@est.tech>
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>