91d7882e86
This is a complete revamp of the original API. Some of the key differences: - refocused on structured parameters and allocating devices - support for constraints across devices - support for allocating "all" or a fixed amount of similar devices in a single request - no class for ResourceClaims, instead individual device requests are associated with a mandatory DeviceClass For the sake of simplicity, optional basic types (ints, strings) where the null value is the default are represented as values in the API types. This makes Go code simpler because it doesn't have to check for nil (consumers) and values can be set directly (producers). The effect is that in protobuf, these fields always get encoded because `opt` only has an effect for pointers. The roundtrip test data for v1.29.0 and v1.30.0 changes because of the new "request" field. This is considered acceptable because the entire `claims` field in the pod spec is still alpha. The implementation is complete enough to bring up the apiserver. Adapting other components follows. |
||
|---|---|---|
| .. | ||
| aggregator_violation_exceptions.list | ||
| apiextensions_violation_exceptions.list | ||
| codegen_violation_exceptions.list | ||
| README.md | ||
| sample_apiserver_violation_exceptions.list | ||
| violation_exceptions.list | ||
Existing API Rule Violations
This folder contains the checked-in report file of known API rule violations. The file violation_exceptions.list is used by Make rule during OpenAPI spec generation to make sure that no new API rule violation is introduced into our code base.
API Rule Violation Format
The report file violation_exceptions.list is in format of:
- API rule violation: <RULE>,<PACKAGE>,<TYPE>,<FIELD>
e.g.
- API rule violation: names_match,k8s.io/api/core/v1,Event,ReportingController
And the violation list is sorted alphabetically in each of the <RULE>, <PACKAGE>, <TYPE>, <FIELD> levels.
How to resolve API Rule Check Failure
Make rule returns an error when the newly generated violation report differs from this checked-in violation report.
Our goal is that exceptions should never be added to this list, only fixed and removed. For new APIs, this is a hard requirement. For APIs that are e.g. being moved between versions or groups without other changes, it is OK for your API reviewer to make an exception.
If you're removing violations from the exception list, or if you have good reasons to add new violations to this list, please update the file using:
UPDATE_API_KNOWN_VIOLATIONS=true ./hack/update-codegen.sh
It is up to API reviewers to review the list and make sure new APIs follow our API conventions.
NOTE: please don't hide changes to this file in a "generated changes" commit, treat it as source code instead.
API Rules Being Enforced
For more information about the API rules being checked, please refer to https://github.com/kubernetes/kube-openapi/tree/master/pkg/generators/rules