This relies on `+k8s:subfield` and validation cohorts. The
`k8s:optional` ensures that we don't run the name validation if name is
empty, because core apimachinery will already flag it as Required().
This demonstrates some of the DV value - docs and clients are now (in
theory) able to see what RC's name format is.
Co-Authored-by: Yongrui Lin <yongrlin@outlook.com>
Other validation errors, like using hostNetwork, don't put
pod.spec.HostNetwork in the error message.
Let's remove align with that.
Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
Now if a pod tries to use user namespaces (hostUsers: false) and a
volume device, it will see this error:
$ kubectl apply -f pod.yaml
...
* spec.ephemeralContainers[0].volumeDevices: Forbidden: when `pod.Spec.HostUsers` is false
* spec.initContainers[0].volumeDevices: Forbidden: when `pod.Spec.HostUsers` is false
* spec.containers[0].volumeDevices: Forbidden: when `pod.Spec.HostUsers` is false
Note that if a pod is already created with volumeDevices and userns,
then we allow modifications to that object.
Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
The hugepage aggregated container limits cannot be greater than pod-level limits.
This was already enforced with the defaulted requests from the specfied
limits, however it did not make it clear about both hugepage requests and limits.
* Add FileKeyRef field and struct to the Pod API
* Add the implementation code in the kubelet.
* Add validation code
* Add basic functionality e2e tests
* add codes for drop disabled pod fields
* update go.mod
* fix: improve the pod level request validation
The pod level request should be larger than the aggregated container
requests. The fix is to skip those resources not supported at the pod
level for better efficiency.
A minor unit test is also added.
* Align with the limit check section using the pod spec to check
existence.
Only validate when feature gate RelaxedServiceNameValidation is enabled.
Also remove name validation on Service updates, as the name is
immutable.
Move ValidateObjectMeta out of ValidateService
Put it into ValidateServiceCreate(), making the code path as such:
```
pkg/registry/core/service/strategy.go
Validate -> validation.ValidateServiceCreate -> ValidateObjectMeta
-> ValidateService
ValidateUpdate -> validation.ValidateServiceUpdate -> ValidateObjectMetaUpdate
-> ValidateService
```
Other resources I checked pass the update objects through
ValidateObjectMeta and ValidateObjectMetaUpdate, so this breaks the
pattern, but it seems to be how the
ValidateObjectMeta/ValidateObjectMetaUpdate functions are designed to
operate.
