dynamic resource allocation: avoid apiserver complaint about list content

This fixes the following warning (error?) in the apiserver:

E0126 18:10:38.665239   16370 fieldmanager.go:210] "[SHOULD NOT HAPPEN] failed to update managedFields" err="failed to convert new object (test/claim-84; resource.k8s.io/v1alpha1, Kind=ResourceClaim) to smd typed: .status.reservedFor: element 0: associative list without keys has an element that's a map type" VersionKind="/, Kind=" namespace="test" name="claim-84"

The root cause is the same as in e50e8a0c919c0e02dc9a0ffaebb685d5348027b4:
nothing in Kubernetes outright complains about a list of items where the item
type is comparable in Go, but not a simple type. This nonetheless isn't
supposed to be done in the API and can causes problems elsewhere.

For the ReservedFor field, everything seems to work okay except for the
warning. However, it's better to follow conventions and use a map. This is
possible in this case because UID is guaranteed to be a unique key.

Validation is now stricter than before, which is a good thing: previously,
two entries with the same UID were allowed as long as some other field was
different, which wasn't a situation that should have been allowed.

Kubernetes-commit: 508cd60760567b3832da748140e3cf782c1b8695
This commit is contained in:
Patrick Ohly 2023-01-26 20:37:00 +01:00 committed by Kubernetes Publisher
parent 648d82831a
commit fa4e59aaee

View File

@ -11415,6 +11415,8 @@ var schemaYAML = typed.YAMLObject(`types:
elementType: elementType:
namedType: io.k8s.api.resource.v1alpha1.ResourceClaimConsumerReference namedType: io.k8s.api.resource.v1alpha1.ResourceClaimConsumerReference
elementRelationship: associative elementRelationship: associative
keys:
- uid
- name: io.k8s.api.resource.v1alpha1.ResourceClaimTemplate - name: io.k8s.api.resource.v1alpha1.ResourceClaimTemplate
map: map:
fields: fields: