feat: add optional DefaultStatus field to ConditionRequirement for missing node conditions

[AnuragThePathak]

Description

Issue #282 already describes why need the DefaultStatus field to act as a problem-gate during node bootstrap. This PR makes the following changes to implement that -

• Introduce a new optional DefaultStatus field in ConditionRequirement. Type Corev1.ConditionStatus.
• Introduce a GetDefaultStatus() accessor for safe access of that field. A kubebuilder schema default is not used due to project policy, so defaulting to Unknown happens at read-time via this method.
• Update the evaluator to use defaultStatus when matching a condition's effective status against requiredStatus for absent conditions.
• Report the actual observed condition status (Unknown) in ConditionEvaluationResult.currentStatus rather than the effective (default-applied) value, preserving the "observed" semantic of the field.
• Populate ConditionEvaluationResult.defaultStatus to reflect what default was configured in the spec, giving full visibility into evaluation decisions.
• Aligned the DryRunResults.riskyOperations logic to strictly count physically missing conditions (adhering to the API schema definition), rather than conflating them with explicitly reported Unknown statuses.
• Regenerate CRD manifests with make manifests to include the new defaultStatus property.

Related Issue

Fixes #282

Type of Change

/kind feature
/kind api-change

Testing

Unit/Integration Tests:

• Added test case verifying getConditionStatus resolves to the configured default status when a condition is missing from a node.
• Added integration test verifying that a node with an absent condition satisfies a rule when the condition's defaultStatus matches requiredStatus (problem-gate scenario).
• Added dry-run integration test verifying that missing conditions on a node trigger riskyOperations increment, even if the condition is satisfied via defaultStatus, and correctly flags taintsToRemove while keeping taintsToAdd at 0.

Validation:

• Verified code compiles, lints, and all tests pass with make test and make lint.
• Ran E2E suite (make test-e2e) locally; all 14 tests passed successfully, ensuring no regressions.

Checklist

• make test passes
• make lint passes

Does this PR introduce a user-facing change?

Added an optional `defaultStatus` field to `ConditionRequirement` (`spec.conditions[]`) in the `NodeReadinessRule` API. This field controls how an absent node condition is evaluated. When omitted, the effective default is `Unknown`, preserving existing behaviour. This enables NRC to function as a problem gate (default-allow) during node bootstrap when integrating with NPD or similar external condition controllers.

Documentation

The following documentation files were updated:

• docs/book/src/introduction.md: Added defaultStatus as a Key Feature.
• docs/book/src/user-guide/getting-started.md: Added defaultStatus as a third field under "Define Readiness Conditions" with a link to Concepts for implications.
• docs/book/src/user-guide/concepts.md: Added a new ### Default Condition Status (defaultStatus) subsection covering:
  • What the field does and what it defaults to when omitted
  • Problem-gate (default-allow) use case for NPD integration
  • [!WARNING] block explicitly documenting that a satisfying defaultStatus must not be used with bootstrap-only rules, as it permanently bypasses the gate
• docs/book/src/reference/api-spec.md: Added defaultStatus rows to both the ConditionRequirement and ConditionEvaluationResult tables, with the Default: Unknown column populated for ConditionRequirement (spec field), and left blank for ConditionEvaluationResult (status field).

[netlify]

✅ Deploy Preview for node-readiness-controller ready!

Name	Link
🔨 Latest commit	d4e52c2
🔍 Latest deploy log	https://app.netlify.com/projects/node-readiness-controller/deploys/6a45316c9151af000881c138
😎 Deploy Preview	https://deploy-preview-283--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.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: AnuragThePathak / name: Anurag Pathak (f351da7)

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: AnuragThePathak
Once this PR has been reviewed and has the lgtm label, please assign tallclair 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 @AnuragThePathak!

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 @AnuragThePathak. 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.

Regular contributors should join the org to skip this step.

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]

@AnuragThePathak Thanks for the PR. Is this ready for review?

[AnuragThePathak]

Yes @ajaysundark you can review the code changes. There are no expected changes unless suggested during review.

In the meantime, I'll keep working on updating the tests which should affect the implementation review.

[ajaysundark]

The direction of the PR looks good to me, publish the PR so the CI kicks in.

We should also document the implications of this feature. For example, defaultStatus doesnt fit for bootstrap-only enforcement mode, where 'unknown' status fit as a better default.

[AnuragThePathak]

@ajaysundark It is good from my side now. By the way you may benefit reviewing by commit, I have created different commit for separate concerns/categories.

[ajaysundark]

/ok-to-test

[AnuragThePathak]

/kind feature
/kind api-change