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 e50e8a0c91:
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.
PV.Spec.CSI.*SecretReference.Name should be allowed to have up to be
limited to 253 characters (DNS1123Subdomain) and not to 63 characters
(DNS1123Label), so all possible Secrets names can be used as secrets in a
PV.
This is continuation of
https://github.com/kubernetes/kubernetes/pull/108331 / Kubernetes 1.25,
which allowed updating PVs with long secret names, if the previous PV had
long secret name too. This makes sure downgrade from 1.27 to 1.26 works well
and allows PVs created in 1.27 to be updated in 1.26.
Now the long secret names are accepted during PV creation too.
A recent commit changed name validation from DNS Subdomain to DNS Label.
The assumption was that a subdomain-named SS could never work and the
only reasonable thing to do would be to delete it. But if there is a
finalizer, the delete is not possible because we would reject the update
because the old name (subdomain) did not pass the new validation.
This commit does not re-validate the ObjectMeta on update. Probably
every resource should follow this pattern, but mostly it's a non-issue
becauase the above change (name validation) is not something we do -
this case was excpetional.
Any StatefuleSet which took advantage of this (by having dots in the
name) can't have worked because we set `pod.spec.hostname` from it,
which is validated as a DNS label.
So while this is strictly a breaking change, it doesn't break anything
that was not already broken.
Add generatod docs for batch v1
Start types with uppercase letters
Fix batch API docs under pgs/apis
Create generated files for batch v1
Fix batch v1beta1 docs
Generate new files after merge conflict
