-
Notifications
You must be signed in to change notification settings - Fork 461
✨ Adds a tool for linting OpenAPI schemas on CRD resources #628
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: munnerz The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Just one failure left, and I'm not sure if it makes sense to change the code here: |
IMO this should be considered a false positive and suppressed with an annotation. |
| return &ExceptionList{Exceptions: make([]Exception, 0)} | ||
| } | ||
|
|
||
| // LoadFromFile will load a pipe (|) separated list of Exceptions from the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doc appears a bit confusing to me. The exception list seems to be separated by newline; one exception per line. But one exception seems to be serialized in a pipe-separated format.
Have you considered other file formats? The suggested format is very compact, but the semantics are not apparent when looking at a file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 the format here wasn't so much chosen to be compact, but rather just to have each entry on a single line to make it clear to see how many violations there are. An example line:
path/to/the/file/jaegertracing.io_jaegers_crd.yaml|jaegers.jaegertracing.io|MaxLengthStrings|spec.versions[0].schema.openAPIV3Schema.properties.spec.properties.collector.properties.volumes.items.properties.flexVolume.properties.fsType.maxLength is not specified on a field of type 'string'
Happy to adjust this format however you feel makes it clearer - what sort of format do you think would be better/what do you have in mind?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@munnerz Sorry for the delay. You have reasonable arguments for selecting the chosen file format, and I think it should be ok. Only downside I see, is that it is not very human readable. The format must remain stable over time, so we should decide if human readability is important now. I'll guess an IDE could be a consumer of these files. Do we have any reference or common practice to refer to?
|
Thanks for the review comments, I'll be updating the PR this week 😄 |
|
I've addressed all the feedback - there's just the one open question on the serialisation format for the exceptions file left :) |
|
@munnerz: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
@munnerz: PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
camilamacedo86
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have we an enhancement proposal for this one?
| | MaxLengthStrings | Ensures that all 'string' type fields have a `maxLength` option set | | ||
| | MaxItemsArrays | Ensures that all 'array' type fields have a `maxItems` option set | | ||
| | SchemaProvided | Ensures that all versions of all CRDs provide an OpenAPI schema | | ||
| | PreserveUnknownFields | Ensures that no fields within a CRD schema permit unknown fields | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is not this attr only valid for v1beta1 CRDs? This project no longer supports or work with v1beta1
| For example: | ||
|
|
||
| ``` | ||
| crd-linter --path ./path/to/crds/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This project is responsible for gen resources?
could you add in the first comment why do you think that this project ought to also linter the resources? I think we need here to know when and why it would be required and used?
Also, would that be a new bin or it would also be hipped with controller-gen? Have we an enhancement proposal for it? and then, why add support to lint only the CRD and not all manifests generated by the project?
| func (p NoPreserveUnknownFields) Description() string { | ||
| return "Fields should avoid using 'preserveUnknownFields' as it means any data can be persisted into the Kubernetes apiserver " + | ||
| "without any guards on the size and type of data. Setting this to true is no longer permitted in the 'v1' API version of " + | ||
| "CustomResourceDefinitions, and as such, it should not be used: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#field-pruning" | ||
| } | ||
|
|
||
| func (p NoPreserveUnknownFields) Execute(crd *v1.CustomResourceDefinition) WarningList { | ||
| var errs []Warning | ||
| if crd.Spec.PreserveUnknownFields { | ||
| errs = append(errs, Warning{Message: "spec.preserveUnknownFields is set to 'true'"}) | ||
| } | ||
| return append(errs, recurseAllSchemas(crd.Spec.Versions, func(props v1.JSONSchemaProps, path string) []Warning { | ||
| if props.XPreserveUnknownFields != nil && *props.XPreserveUnknownFields == true { | ||
| return newWarningList(fmt.Sprintf("%s.x-kubernetes-preserve-unknown-fields is set to 'true'", path)) | ||
| } | ||
| return nil | ||
| })...) | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The description mentions that v1 forbids it, but that seems to be true only to spec.preserveUnknownFields and not to x-kubernetes-preserve-unknown-fields on specific properties. Am I missing something?
|
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
|
/remove-lifecycle stale I would like to use this tool! 😊 |
|
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
|
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
|
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
|
@k8s-triage-robot: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
This PR adds a new CLI tool named
crd-linterwhich will lint/run checks against CRD resources and their corresponding schema.Initially this includes just 4 linters to check for:
provideUnknownFieldsandx-kubernetes-preserve-unknown-fieldsis not usedstringtyped fields have amaxLengthspecifiedarraytyped fields have amaxItemsspecifiedThis is all in the effort to ensure a higher quality of CRDs, which helps protect apiservers against e.g. too much data being stored in a CRD, or ever-growing number of items in arrays that can cause scalability issues.
These linters aren't aimed at all being "best practice", but providing this tool allows teams to check for potential issues/better understand APIs they are installing and where issues may be found.
I'm not sure where this is best to live, nor am I wedded to any parts of the design of it, so welcome any and all feedback 😄
ref https://kubernetes.slack.com/archives/C0EG7JC6T/p1628592082067800