Validate capacity request and allocation-result maps, rejecting negative
quantities, invalid capacity names, and more than 32 entries. Use
declarative validation for map sizes and quantities while preserving
updates to unchanged fields accepted under earlier validation.
Reject raw negative requests before request-policy rounding in both
allocator variants. Reject negative consumed quantities and computed
node-allocatable resource footprints.
Return errors when persisted or in-flight allocations contain negative
consumed capacity, preventing positive allocations from masking invalid
values in the aggregate. Clear recorded errors when invalid claims are
removed.
Co-authored-by: Krishna Parihar <krishnasparihar88@gmail.com>
getScheduledPodsTopologyDomain used an empty topologyDomain string as the
"no domain seen yet" marker. Because "" is also a legal label value, a first
pod on a node labeled with an empty topology value let a pod in a genuinely
different domain slip past the "more than 1 domain" check, and the group's
required domain silently resolved to "".
Rather than teach the check about "" as a real domain, treat an empty label
value as a node labeling mistake that does not form a domain:
- GeneratePlacements ignores nodes whose topology label is empty, so new pod
groups are never placed onto them.
- getScheduledPodsTopologyDomain returns an explicit error when an already
scheduled pod sits on such a node.
- TopologyConstraint.Key documents that nodes with a missing or empty label
value do not belong to any domain (v1alpha3 and v1beta1).
PodTopologySpread and InterPodAffinity still accept empty values; that is
existing behavior and is left alone.
Signed-off-by: yuzhiquan <yuzhiquanlong@gmail.com>
API comments claimed percentage maxUnavailable is rounded up. The
controller rounds down to a minimum of 1 (getStatefulSetMaxUnavailable),
matching KEP-961 and the unit tests. Align the docs with the behavior;
do not change rollout behavior of a beta field.
The OpenAPI snapshots checked in under client-go/openapi/openapitest,
kubectl/testdata and cli-runtime/artifacts still described the field as
alpha-level and gated on MaxUnavailableStatefulSet. Sync that
description with the regenerated spec text too.
GitRepoVolumeSource, PodResizeStatus and the internal NodeConfigSource
types are deprecated types, not deprecated API versions, so their
notices stay; GitRepo's gets the Deprecated: casing.
Nothing prevents DRA drivers and users from publishing resp. requesting the
same capacity with and without driver name prefix.
Validation could prevent this for ResourceSlices (driver name is known) but
doesn't. It's probably also not worth doing because DRA drivers are trusted and
can trivially avoid this; validation would just add overhead. Lookup for
constraints resolves this conflict via "fully-qualified wins". Consumable
capacity resolution was random (last one in map iteration wins), now also
prefers fully-qualified. This is arbitrary, but shouldn't happen in practice.
Validation cannot prevent this for a ResourceClaim capacity request because the
driver name depends on the device under evaluation. This is something that
users could get wrong and the simplistic "prefer fully-qualified" would lead to
surprising results, so instead this is considered an error and causes pod
scheduling to fail if (and only if) it is detected for a device.
When the ResourceClaim requested "driver.example.com/bandwidth" and that DRA
driver published the capacity as "bandwidth", the request failed. Same for the
inverse case.
A less likely problem existed when a DRA driver flipped between publishing with
and without its own driver name as prefix: the allocation result stored
literally what came from the driver at the time of allocation, which then
wouldn't be considered after flipping to the other format.
The fix is to normalize names (drop redundant prefix) before comparing. The
allocation result is written with the same name as in the ResourceSlice,
mimicking the behavior in Kubernetes 1.37. The DRA CPU driver 0.2.0 depends on
that (will be fixed) and Kubernetes 1.37 also did a literal string comparison,
so copying names from the ResourceSlice is required for downgrades.
While at it, the code gets cleaned up a bit:
- Some methods were exported unnecessarily.
- Their parameters can be simplified by passing through a deviceWithID.
For an exported method that would not be the right API, but internally
it's fine and simpler.
Node.status.volumesAttached[].devicePath is documented as a device path,
but its value is platform and plugin specific: on Linux nodes it is the
host block-device node (e.g. /dev/xvdX), while on Windows nodes it carries
the CSI VolumeID, since Windows has no /dev device tree.
Update the API field documentation and the generated artifacts to state
the platform variance, and annotate the kubelet detach path so the
unix-only device-in-use check (hostutil.PathIsDevice/DeviceOpened) is no
longer silently dead code on Windows.
Refers to the reported issue in the PR description.
Signed-off-by: abhinav-phi <alpha9coder@gmail.com>
Enables optionalorrequired and nonpointerstructs kube-api-linter rules for the networking API group (part of #134671).
- Tags HTTPIngressRuleValue.Paths, HTTPIngressPath.PathType (v1 only), IngressServiceBackend.Name, and IngressClassSpec.Controller as +required based on validation rules.
- Marks IngressPortStatus.Port and Protocol as +optional matching validation logic.
- Suppresses HTTPIngressPath.Backend and IngressServiceBackend.Port in exceptions.yaml as they represent oneOf struct fields with cross-field validation rules.
- Regenerates OpenAPI specs, swagger, and protobuf definitions.
The doc comment on ResourceFieldSelector.Divisor claimed the field
"defaults to 1". There is no server-side defaulting for the field: an
object written without a divisor is read back with an explicit 0, and
only the consumers of the field treat an unset or 0 divisor as 1.
Update the comment in pkg/apis/core/types.go and
staging/src/k8s.io/api/core/v1/types.go to describe both meanings, using
the wording proposed by the API approver. Comment-only change; the
generated protobuf, swagger doc, applyconfiguration and OpenAPI outputs
are regenerated with hack/update-codegen.sh and
hack/update-openapi-spec.sh. No API behaviour changes.
Antoni Zawodny