[#435] fix: webhook taint conflict check incorrectly rejects dry-run rules

[tejassinghbhati]

Summary

The validation webhook blocks creation of a dryRun: true rule whenever an enforcement rule already manages the same taint key on overlapping nodes. Because dry-run rules never write taints to nodes, they cannot produce the concurrent-update conflict the guard is designed to prevent. The rejection is a false positive that makes the primary use case for dryRun, previewing the impact of a new rule against a taint key already in active use is impossible when the webhook is enabled.

Root cause

validateTaintConflicts iterates all existing rules and flags any pair sharing taint.key + taint.effect on overlapping selectors. It does not check spec.dryRun on either side, so it treats dry-run rules as if they were enforcement rules.

Fix

Add an early continue inside validateTaintConflicts when either the incoming or the existing rule has Spec.DryRun set:

// Dry-run rules never write taints, so they cannot produce a real // conflict regardless of taint key or selector overlap.
if rule.Spec.DryRun || existingRule.Spec.DryRun {
    continue
}

Tests

Two regression tests added to nodereadinessgaterule_webhook_test.go:

1. A dryRun: true rule with the same taint key as an existing enforcement rule on overlapping nodes is accepted.
2. An enforcement rule is accepted when a dryRun: true rule already exists for the same taint key on overlapping nodes.

go test ./internal/webhook/... — 41 passed, 0 failed.

Related issue

Fixes #435

Type of change

/kind bug

Checklist

• go build ./... passes
• go test ./internal/webhook/... passes (41 tests, no envtest required)

Does this PR introduce a user-facing change?

NONE

[netlify]

✅ Deploy Preview for node-readiness-controller canceled.

Name	Link
🔨 Latest commit	7ba9f0a
🔍 Latest deploy log	https://app.netlify.com/projects/node-readiness-controller/deploys/6a860108b98fe40008a798e9

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: tejassinghbhati
Once this PR has been reviewed and has the lgtm label, please assign ajaysundark 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]

Hi @tejassinghbhati. 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.

[ajaysundark]

Hi, thanks for raising the PR. I am not clear where this is needed. I asked a question on the issue #435 (comment), can we discuss this further before arriving at a fix?

[tejassinghbhati]

Sounds good,
Actually I just replied on the issue with the use case and safety details, let's continue the discussion over there.