Skip to content

Commit 36dd649

Browse files
committed
docs: update api_changes.md and api_conventions.md with declarative validation information
1 parent fb2f95f commit 36dd649

File tree

2 files changed

+52
-1
lines changed

2 files changed

+52
-1
lines changed

contributors/devel/sig-architecture/api-conventions.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1953,7 +1953,7 @@ the future, an HTTP/2 implementation will be exposed that deprecates SPDY.
19531953

19541954
## Validation
19551955

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
19571957
flagged and returned to the caller in a `Failure` status with `reason` set to
19581958
`Invalid`. In order to facilitate consistent error messages, we ask that
19591959
validation logic adheres to the following guidelines whenever possible (though

contributors/devel/sig-architecture/api_changes.md

Lines changed: 51 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -645,6 +645,56 @@ optionality of fields.
645645

646646
Of course, code needs tests - `pkg/apis/<group>/validation/validation_test.go`.
647647

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+
type ReplicationControllerSpec struct {
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.
686+
// +k8s:optional
687+
// +k8s:minimum=0
688+
MinReadySeconds int32 `json:"minReadySeconds,omitempty"`
689+
}
690+
```
691+
692+
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+
648698
## Edit version conversions
649699

650700
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.
698748

699749
Apart from the `defaulter-gen`, `deepcopy-gen`, `conversion-gen` and
700750
`openapi-gen`, there are a few other generators:
751+
- `validation-gen` (for generating validation functions from declarative tags)
701752
- `go-to-protobuf`
702753
- `client-gen`
703754
- `lister-gen`

0 commit comments

Comments
 (0)