You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: contributors/devel/sig-architecture/api-conventions.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1953,7 +1953,7 @@ the future, an HTTP/2 implementation will be exposed that deprecates SPDY.
1953
1953
1954
1954
## Validation
1955
1955
1956
-
API objects are validated upon receipt by the apiserver. Validation errors are
1956
+
API objects are validated upon receipt by the apiserver. Validation can be implemented in two ways: declaratively, using tags on the Go type definitions, or manually, by writing validation functions. For all new APIs, declarative validation is the preferred approach for the validation rules it supports. For more information see the [declarative validation documentation](api_changes.md). Validation errors are
1957
1957
flagged and returned to the caller in a `Failure` status with `reason` set to
1958
1958
`Invalid`. In order to facilitate consistent error messages, we ask that
1959
1959
validation logic adheres to the following guidelines whenever possible (though
Copy file name to clipboardExpand all lines: contributors/devel/sig-architecture/api_changes.md
+51Lines changed: 51 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -645,6 +645,56 @@ optionality of fields.
645
645
646
646
Of course, code needs tests - `pkg/apis/<group>/validation/validation_test.go`.
647
647
648
+
### Declarative Validation
649
+
650
+
For new APIs, developers should use declarative validation for all validation rules that declarative validation supports. See the [declarative validation tag catalog](https://kubernetes.io/docs/reference/using-api/declarative-validation/) for the list of supported validation rules. This allows you to define validation rules directly on the API types using special Go comment tags. Using this validation rules are easier to write, review, and maintain as they live alongside the type and field definitions.
651
+
652
+
A new code generator, `validation-gen`, processes these tags to produce the validation logic automatically, reducing the need to write manual validation code in `validation.go`.
653
+
654
+
655
+
To use declarative validation below are broadly steps to setup the validation code generation. For APIs already using declarative validation, the first 2 plumbing steps can be skipped:
656
+
- Register the desired API group with validation-gen, similar to other code generators([Example PR doc.go change](https://github.com/kubernetes/kubernetes/pull/130724))
657
+
- Wire up the `strategy.go` for the desired API group to use declarative validation ([Example PR strategy.go change](https://github.com/kubernetes/kubernetes/pull/130724))
658
+
- Add declarative validation tags to the types and fields of the registered package ([Example PR types.go change](https://github.com/kubernetes/kubernetes/pull/130725))
659
+
- Run the validation-gen code generator (see below)
660
+
661
+
Below is an example of how to register an API group with validation-gen:
662
+
663
+
`pkg/apis/core/v1/doc.go`
664
+
```go
665
+
...
666
+
// +k8s:validation-gen=TypeMeta
667
+
// +k8s:validation-gen-input=k8s.io/api/core/v1
668
+
669
+
// Package v1 is the v1 version of the API.
670
+
package v1
671
+
```
672
+
673
+
Below is an example of how to use declarative validation tags in a `types.go` file:
674
+
675
+
```go
676
+
// ReplicationControllerSpec is the specification of a replication controller.
677
+
typeReplicationControllerSpecstruct {
678
+
// Replicas is the number of desired replicas.
679
+
// This is a pointer to distinguish between explicit zero and not specified.
680
+
// +k8s:optional
681
+
// +k8s:minimum=0
682
+
Replicas *int32`json:"replicas,omitempty"`
683
+
684
+
// Minimum number of seconds for which a newly created pod should be ready
685
+
// without any of its container crashing, for it to be considered available.
In this example, the `+k8s:optional` and `+k8s:minimum=0` tags specify that the `Replicas` and `MinReadySeconds` fields are optional and must have a value of at least 0 if present.
693
+
694
+
After adding these tags to your types, you will need to run the code generator to create or update the validation functions. This is typically done by running `make update` or `hack/update-codegen.sh`. To only run the declarative validation code generator, use `hack/update-codegen.sh validation`. Running the validation-gen code generator will create a `zz_generated.validations.go` file for the declarative validations of the associated tagged API types and fields. The generated validation methods in this file are then called via the modified `strategy.go` file in the above steps.
695
+
696
+
While the goal is to express as much validation declaratively as possible, some complex or validation rules might still require manual implementation in `validation.go`.
697
+
648
698
## Edit version conversions
649
699
650
700
At this point you have both the versioned API changes and the internal
@@ -698,6 +748,7 @@ workaround is to remove the files causing errors and rerun the command.
698
748
699
749
Apart from the `defaulter-gen`, `deepcopy-gen`, `conversion-gen` and
700
750
`openapi-gen`, there are a few other generators:
751
+
-`validation-gen` (for generating validation functions from declarative tags)
0 commit comments