github/kubernetes
1
0
Fork 0
mirror of https://github.com/k3s-io/kubernetes.git synced 2026-07-19 07:25:19 +00:00
Code Issues Projects Releases Wiki Activity

Rewrite Subresources godoc.

Browse Source
This commit is contained in:
Joe Betz
2025-04-14 14:42:34 -04:00
parent 164fefa948
commit 2e8b409a5f
1 changed files with 21 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
staging/src/k8s.io/apimachinery/pkg/api/operation/operation.go
View File

@@ -49,16 +49,27 @@ type Operation struct {
// Request provides information about the request being validated.
type Request struct {
// Subresources is the path to the subresource being validated. Validations
// should use this only when the validation of field differs for a particular
// subresource. For example, the resize subresource of pod is allowed to change
// the value of spec.container[*].resources fields, which are immutable updated
// via the root pod resource. In this example, because validation of the fields
// are conditional to the subresource, the validator should use Subresources.
// Note field wiping, which limits which fields a subresource is allowed to write
// to, is handled in strategies, and does should to be implemented using
// Subresources since field wiping drops field changes from the request, but does
// not require changes to validation logic.
// Subresources identifies the subresource path components of the request. For
// example, Subresources for a request to `/api/v1/pods/my-pod/status` would be
// `["status"]`. For `/api/v1/widget/my-widget/x/y/z`, it would be `["x", "y",
// "z"]`. For a root resource (`/api/v1/pods/my-pod`), Subresources will be an
// empty slice.
//
// Validation logic should only consult this field if the validation rules for a
// particular field differ depending on whether the main resource or a specific
// subresource is being accessed. For example:
//
// Updates to a Pod resource (`/`) normally cannot change container resource
// requests/limits after the Pod is created (they are immutable). However, when
// accessing the Pod's "resize" subresource (`/resize`), these specific fields
// are allowed to be modified. In this scenario, the validation logic for
// `spec.container[*].resources` must check `Subresources` to permit changes only
// when the request targets the "resize" subresource.
//
// Note: This field should not be used to control which fields a subresource
// operation is allowed to write. This is the responsibility of "field wiping".
// Field wiping logic is expected to be handled in resource strategies by
// modifying the incoming object before it is validated.
Subresources []string
}