Skip to content

Update declarative validation docs for current validation-gen workflow#9059

Open
yongruilin wants to merge 1 commit into
kubernetes:mainfrom
yongruilin:docs/declarative-validation-update
Open

Update declarative validation docs for current validation-gen workflow#9059
yongruilin wants to merge 1 commit into
kubernetes:mainfrom
yongruilin:docs/declarative-validation-update

Conversation

@yongruilin

Copy link
Copy Markdown
Contributor

Refresh the API changes and conventions guides to match how declarative
validation works today.

  • Plumbing is already wired for in-tree API groups, so the workflow is now
    just: add tags, regenerate, and test.
  • Document runtime gating via +k8s:ifEnabled/+k8s:ifDisabled and the
    strategy's DeclarativeValidationConfig.
  • Document rollout/migration staging via +k8s:alpha/+k8s:beta.
  • Remove the outdated strategy.go wiring guidance and stale example PR links.

Which issue(s) this PR fixes:

Fixes #

Refresh the API changes and conventions guides to match how declarative
validation works today: plumbing is already wired for in-tree groups, so
the workflow is add tags, regenerate, and test. Document runtime gating
via +k8s:ifEnabled/+k8s:ifDisabled with DeclarativeValidationConfig, and
rollout/migration staging via +k8s:alpha/+k8s:beta. Remove the outdated
strategy.go wiring guidance and stale example PR links.
@kubernetes-prow kubernetes-prow Bot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. area/developer-guide Issues or PRs related to the developer guide size/L Denotes a PR that changes 100-499 lines, ignoring generated files. sig/architecture Categorizes an issue or PR as relevant to SIG Architecture. labels Jun 30, 2026
@kubernetes-prow kubernetes-prow Bot requested review from dims and johnbelamaric June 30, 2026 20:51
@kubernetes-prow kubernetes-prow Bot added the sig/contributor-experience Categorizes an issue or PR as relevant to SIG Contributor Experience. label Jun 30, 2026
@yongruilin

Copy link
Copy Markdown
Contributor Author

/assign @jpbetz
/assign @lalitc375

@yongruilin

Copy link
Copy Markdown
Contributor Author

/sig api-machinery

@kubernetes-prow kubernetes-prow Bot added the sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. label Jun 30, 2026
@lalitc375

Copy link
Copy Markdown

/lgtm
/approve

@kubernetes-prow kubernetes-prow Bot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jun 30, 2026
@kubernetes-prow

Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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

@yongruilin

Copy link
Copy Markdown
Contributor Author

/cc @dims
/cc @johnbelamaric
For approval, thanks!

@dims

dims commented Jul 1, 2026

Copy link
Copy Markdown
Member

/assign @liggitt

Comment on lines +2017 to +2018
supports, and existing hand-written validation should be migrated to declarative
tags where possible. For the supported tags and how to apply them, see the

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's drop the recommendation to migrate hand-written validation from here for now

for the catalog of supported tags.

Declarative validation is already wired for the in-tree API groups, so for an
existing resource you do not need to touch `doc.go` or `strategy.go` — add tags,

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
existing resource you do not need to touch `doc.go` or `strategy.go`add tags,
existing resource you do not need to touch `doc.go` or `strategy.go`. You only need to add tags to the versioned `types.go` files,


Then regenerate with `hack/update-codegen.sh validation` (or `make update`),
which writes a `zz_generated.validations.go` file in each tagged package. Finally,
add Go unit tests just as you would for hand-written validation, asserting which

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These need to be added in a special location for the coverage detection to work, right? can we point at docs for how to do that? (can be done in a follow-up if you want)

func (autoscalerStrategy) DeclarativeValidationConfig(ctx context.Context, obj, oldObj runtime.Object) rest.DeclarativeValidationConfig {
var options []string
enabled := utilfeature.DefaultFeatureGate.Enabled(features.HPAScaleToZero)
if !enabled && oldObj != nil {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need to do the oldObj detection for ratcheting for DV tags? I thought we got ratcheting for free for all DV tags already

enabled = old.Spec.MinReplicas != nil && *old.Spec.MinReplicas == 0
}
if enabled {
options = append(options, "HPAScaleToZero")

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jpbetz I keep forgetting we have to manually inject string feature validation for ifEnabled/ifDisabled to work, and unknown options are silently treated as false ... let's make sure kubernetes/kubernetes#139197 gets prioritized. I would not be surprised if we already have ifEnabled/ifDisabled rules that aren't doing what they think they are because of this


#### Staging a rule with `+k8s:alpha` and `+k8s:beta`

A tag may carry a lifecycle prefix that controls whether it is enforced or only

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's probably worth explaining that this is only expected to be used when migrating from hand-written validation to declarative validation. For new APIs / new fields, I would not expect this to be used at all

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/developer-guide Issues or PRs related to the developer guide cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. sig/architecture Categorizes an issue or PR as relevant to SIG Architecture. sig/contributor-experience Categorizes an issue or PR as relevant to SIG Contributor Experience. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants