- Add new version fields to version.Info struct:
* EmulationMajor and EmulationMinor to track emulated version
* MinCompatibilityMajor and MinCompatibilityMinor for compatibility tracking
- Update related code to populate and use these new fields
- Improve version information documentation and OpenAPI generation
- Modify version routes and documentation to reflect new version information structure
.spec.serviceName field is injected into pod.spec.subDomain which
requires values to be valid DNS1123 label, but statefulset validation
never validates the field, if specifired. This can cause the controller
to fail creating pods.
Signed-off-by: Maciej Szulik <soltysh@gmail.com>
We plan to add more formats in upcoming releases.
This tracks which formats are introduced at a version.
Unrecognized formats remain ignored. That is,
if a format is not supported at the emulated version,
the format is not enforced. This differs from typical
field handling, where unsupported field values are
forbidden. This is pre-existing behavior and is
in compliance with JSON Schema's format handling.
Ratcheting of custom resources helps with the introduction
of new formats. When a cluster is upgraded to a version
of Kubernetes that supports a format already set (but not enforced)
in a custom resource definition, the format will start
being enforced against custom resources. Ratcheting will
tolerate unchanged values of custom resources, even
if the value is not valid according to the format.
Add validation.IsValidIPForLegacyField and
validation.IsValidCIDRForLegacyField, which validate "legacy" IP/CIDR
fields correctly. Use them for all such fields (indirectly, via a
wrapper in pkg/apis/core/validation that handles the
StrictIPCIDRValidation feature gate correctly).
Change IsValidIP and IsValidCIDR to require strict parsing and
canonical form, and update the IPAddr, ServiceCIDR, and
NetworkDeviceData validation to make use of them.
This PR changes the TestListOptions setup to execute compaction before
we start apiserver allowing the test work with cache snapshots from
KEP-4988 by preventing creation of snapshots for compacted revisions.
While etcd compaction removes access to old revision, with KEP-4988
those revisions will be still available in watch cache. Implementing
compaction for watch cache doesn't make sense as it would only be
used for testing, making it unreliable.
To properly test how etcd and watch cache behaves on
compacted revisions we need to compact etcd before we start apiserver.
Graduate the feature to beta, by:
- Allowing `subPath`/`subPathExpr` for image volumes
- Modifying the CRI to pass down the (resolved) sub path
- Adding metrics which are outlined in the KEP
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
