feat: label the CRD with its managing installation and guard duplicat…

[yindia]

Summary

Stamps the NodeReadinessRule CRD with a managed-by label naming the installation that owns it, and refuses a fresh helm install when the CRD already exists.

Design notes

Why the CRD carries the label. It's cluster scoped and singleton, so it's the one artifact every install flow contends over. It's set with a controller-gen marker, so make manifests regenerates it in config/crd/bases, and verify-chart-drift.sh diffs that against the chart's crds/ copy to catch the two drifting apart.

Why a template guard, not a pre-install hook. The Helm guard uses lookup + fail in a template — same outcome without a ServiceAccount, ClusterRole or image, and it aborts at render time so the guidance lands in the terminal rather than Job logs.

Why it's keyed on .Release.IsInstall plus CRD existence, not the label value. Both installs may be carrying the default value, and that's precisely the accident being guarded against, so a value comparison would pass straight through it. Upgrades skip the check naturally.

Two things worth a reviewer's attention

Label is CRD-only. Helm 3 forces managed-by: Helm on resources it owns, so stamping the Deployment/RBAC/Services doesn't stick. The CRD works because Helm neither templates nor tracks crds/.

Guard only covers helm install. kubectl apply, kustomize and the static-pod path have none. A controller startup check would close the gap, but it's ruled out by alternative (1) in the issue — left out and documented. Happy to reconsider.

Also included

Chart-rendered NodeReadinessRule CRs now get the standard chart labels, which they were missing. Unrelated tidy-up, happy to split it out.

Related Issue

Fixes #438

Type of Change

/kind feature

Testing

• helm install into a clean cluster: CRD is created with app.kubernetes.io/managed-by=node-readiness-controller.
• helm install with a second release name while the CRD exists: render aborts with the guidance message, nothing is applied.
• helm upgrade on the existing release: check is skipped, upgrade succeeds.
• helm template output diffed against dist/crds.yaml; verify-chart-drift.sh passes.

Checklist

• make test passes
• make lint passes

Does this PR introduce a user-facing change?

Yes

`helm install` now fails when a `NodeReadinessRule` CRD from another installation is already present in the cluster. The CRD carries a `managed-by` label identifying the owning installation.

[netlify]

✅ Deploy Preview for node-readiness-controller ready!

Name	Link
🔨 Latest commit	55e6a23
🔍 Latest deploy log	https://app.netlify.com/projects/node-readiness-controller/deploys/6a89baa2b8aea300082b1c6f
😎 Deploy Preview	https://deploy-preview-440--node-readiness-controller.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: yindia
Once this PR has been reviewed and has the lgtm label, please assign haircommander for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kubernetes-prow]

Welcome @yindia!

It looks like this is your first PR to kubernetes-sigs/node-readiness-controller 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/node-readiness-controller has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[kubernetes-prow]

Hi @yindia. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Tip

We noticed you've done this a few times! Consider joining the org to skip this step and gain /lgtm and other bot rights. We recommend asking approvers on your previous PRs to sponsor you.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[yindia]

@ajaysundarkI'm not sure it's the best approach, it false-positives on reinstall since Helm keeps crds/ CRDs after uninstall. Open to a better ideas if anyone has one

[DsThakurRawat]

On the uninstall/reinstall false positive:

The reason lookup on the CRD trips is that Helm 3 leaves crds/ in place on helm uninstall by design. If crd-ownership-check.yaml fails solely on CRD presence, any standard helm uninstall -> helm install cycle in the same cluster gets blocked.

Two ways to resolve this without dropping the guard:

1. Guard on active workload presence rather than CRD presence: query for the Deployment in the target namespace (lookup "apps/v1" "Deployment" .Release.Namespace (include "node-readiness-controller.fullname" .)). Helm deletes the Deployment on uninstall, so a fresh install after an uninstall proceeds cleanly, while a true concurrent installation in that namespace is caught.
2. If the goal is catching hosted provider installs where the Deployment lives in a hidden namespace, check the label value rather than existence: only abort if $existing.metadata.labels["app.kubernetes.io/managed-by"] exists AND is not equal to "Helm" / our default manager. That way, lingering unmanaged CRDs from a previous uninstall do not block a fresh install.