Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Helm operator: namespace scope resources with Helm keep annotations are being deleted by garbage collection #4378

Closed
mikeshng opened this issue Jan 8, 2021 · 1 comment · Fixed by #4389 or operator-framework/helm-operator-plugins#71
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. language/helm Issue is related to a Helm operator project
Milestone

Comments

@mikeshng
Copy link
Contributor

mikeshng commented Jan 8, 2021

Bug Report

What did you do?

I created a sample Helm operator, then modified one of the namespace scope resources in the template to contain:

metadata:
  annotations:
    "helm.sh/resource-policy": keep

see "Tell Helm Not To Uninstall a Resource" in: https://helm.sh/docs/howto/charts_tips_and_tricks for more details.

After applying the Helm sample CR and then proceed to delete it, the resource with the keep annotation is also deleted from the cluster.

When I tried the same annotation on a cluster scope resource, that resource is not deleted so I think the issue is due to parent child garbage collection with namespace scope resources.

What did you expect to see?

If possible, it would be nice to have the namespace resources that are annotated with the keep to still exists after the CR is deleted. Or the website/doc should mention that keep annotation is not supported for namespace scope resources.

What did you see instead? Under which circumstances?

namespace scope resources with Helm keep annotations are being deleted when the Helm operator CR is removed.

Environment

Operator type:
/language helm

Kubernetes cluster type:
kind

$ operator-sdk version

operator-sdk version: "v1.3.0-7-g8c31ab8f", commit: "8c31ab8fdbbe572a94a10c8f0dff33bbb53beb38", kubernetes version: "v1.19.4", go version: "go1.14.1", GOOS: "linux", GOARCH: "amd64"

$ kubectl version

Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2-0-g52c56ce", GitCommit:"b66f2d3a6893be729f1b8660309a59c6e0b69196", GitTreeState:"clean", BuildDate:"2020-08-10T04:49:09Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0", GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf", GitTreeState:"clean", BuildDate:"2020-01-14T00:09:19Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"}

Possible Solution

@openshift-ci-robot openshift-ci-robot added the language/helm Issue is related to a Helm operator project label Jan 8, 2021
@estroz estroz added good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. labels Jan 11, 2021
@estroz estroz added this to the Backlog milestone Jan 11, 2021
@joelanford
Copy link
Member

@mikeshng I think this is happening because the helm-operator injects an owner reference into all the resources in the manifest. So when the CR is deleted, first a helm uninstall happens (which wouldn't delete these resources), then the CR finalizer is removed and the CR is deleted, then Kubernetes GCs all owned resources.

I think the fix would be to NOT inject owner references into resources that have this annotation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. language/helm Issue is related to a Helm operator project
Projects
None yet
4 participants