kubernetes / kubernetes/kube-openapi
Support +k8s:-prefixed tags to align with declarative validation
- 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
Assessment
This issue has not been assessed yet.