add missing metric about uncore / L3 / Last-Level cache alignment,
plus its e2e tests.
Exposing uncore alignment requires a bit of refactoring in the static
policy implementation because, differently from full PCPUs alignment
and NUMA alignment, can't be easily and safely inferred by construction.
The main reason for this is that uncore cache alignment is preferred,
not mandatory, thus the cpu allocator can legally use cross-uncore
allocation. Because of that, the final cpuset union step can
create a final cpuset which is not uncore-aligned even though all
its parts are uncore-aligned.
The safest way seems thus to run just a final uncore-alignment check
once the final cpuset is computed.
Signed-off-by: Francesco Romani <fromani@redhat.com>
- 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.
