kubernetes / kubernetes/kube-openapi

Support +k8s:-prefixed tags to align with declarative validation

Open
#638 1 comment 0 reactions 1 assignee Claimed by @yongruilin View on GitHub
Dominant language
Go
Stars
356
Forks
249
Avg merge
1d 15h
Merged PRs (30d)
3

Description

Declarative validation introduced `+k8s:`-prefixed tags that duplicate several tags kube-openapi already reads (`+k8s:optional` vs `+optional`, `+k8s:listType` vs `+listType`, and others). Today API authors have to write both. The goal is for kube-openapi to accept the prefixed spelling so the unprefixed ones can eventually be dropped.

Since both spellings will coexist during the migration, each tag must be recognized as an alias — parsed once, with no change to generated output for fields that carry both.

- [x] `+k8s:optional` / `+k8s:required` — in progress (#639 )
- [ ] `+k8s:listType` and `+k8s:enum` — straightforward aliases
- [ ] `+k8s:listMapKey` and the union tags — these need design discussion, not a rename. DV expresses map-ness via `+k8s:unique=map` rather than `listType=map`, and DV marks union *members* (`+k8s:unionMember`) where kube-openapi marks the *struct* (`+union`).

Not in scope: `+mapType`, `+structType`, `+patchStrategy`, `+patchMergeKey` have no declarative validation counterpart. `+default` goes the other way — validation-gen reads the unprefixed tag today and plans to move to `+k8s:default`.

`+k8s:format` overlaps kube-openapi's `+k8s:validation:format`; the format values themselves are tracked separately in #597.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.