As suggested in
https://github.com/kubernetes/website/pull/48330#discussion_r1799302946, the
front matter gets extended to reference the API types. To make this work,
the necessary API reference files get created manually. They still need to be
updated via the usual automatic API generation.
The concepts are mostly the same as before. Support for parameters in a CRD was
removed in favor of storing selection and configuration parameters directly in
ResourceClaim and DeviceClass.
Replace the feature gate descriptions so that there is a Markdown file
for each feature gate.
Use a shortcode to render a feature gate description. If you use the
shortcode, this also validates that any feature gate you reference
has exactly one descriptive text for the current localization.
Localizations can adopt this new approach piecemeal.
Likely benefits:
- when feature gates are removed from Kubernetes, the localization work
to do won't require any language skills
- merge conflicts are less likely because the list of feature gates
becomes just a list of names (descriptions are elsewhere, so changes
that just affect descriptions won't cause a conflict)
- we'll have a machine-readable list of all the feature gates we
document, and can compare that to other lists if we want to
- we'll gain a place to add metadata about feature gates. For example,
this lays groundwork for a future change where we record the KEP
number (if known) for a feature gate, and can render that where it's
useful.
Patrick Ohly
Dipesh Rawat
Tim Bannister