-
Notifications
You must be signed in to change notification settings - Fork 40k
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
Add e2e test for API coverage #57171
Conversation
c246b6c
to
9f9ec17
Compare
/retest |
498ed9d
to
d21e49e
Compare
@roycaihw: GitHub didn't allow me to request PR reviews from the following users: mithrav. Note that only kubernetes members and repo collaborators can review this PR, and authors cannot review their own PRs. |
@kubernetes/sig-api-machinery-pr-reviews |
Wow, this looks like a maintenance nightmare. What is is goal? Is any/most of this generated? @liggitt @derekwaynecarr called it? |
If we want to include this in conformance, one thing we'll need to figure out is how to exclude APIs that should not be covered. The existing coverage data already shows that some machinery is probing paths that should be excluded. https://gist.github.com/oomichi/bc0044624443b4b596bdb4c83dd4ad4b cc @kubernetes/sig-architecture-pr-reviews |
@deads2k The goal is to use a table driven test to verify if a Kubernetes cluster exposes endpoints an end user would reasonably expect. This test doesn't verify the correct behavior of those APIs, but just checks if the endpoints exist (as a necessary but not sufficient step). For the maintenance, may I ask if you are talking about the list of APIs or the yaml test data? The API list is generated by bringing up a cluster and using discovery API. The yaml test data is collected from the code base and kubernetes.io. It would be better if we could generate those yaml files from the schema/Go types. But if we manually maintain them, are we expecting the yaml file will be invalid (broken) for a beta/GA API frequently? |
subresources resourceMap | ||
} | ||
|
||
var _ = SIGDescribe("Coverage", func() { |
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 belong into some test/e2e/coverage folder. It tests coverage of Kubernetes APIs, it's not about generic API features.
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 comment still applies.
Please squash. You should have time since the tests are failing. |
c7e8750
to
44426d2
Compare
ace194a
to
dd3d069
Compare
@mml Squashed. PTAL /test pull-kubernetes-e2e-kops-aws |
/lgtm |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: mml, roycaihw Assign the PR to them by writing The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
`hack/update-api-resource-list.sh` and `hack/verify-api-resource-list.sh` generate and verify list of api resources served by kube apiserver. `test/e2e/testing-manifests/apiresource/resources_all.csv` is the generated list of all api resources served by kube apiserver. `test/e2e/testing-manifests/apiresource/resources_whitelist.csv` is the whitelist of api verbs that we are not covering in api coverage test `test/e2e/testing-manifests/apiresource/resources.csv` is the actual list of api verbs that we test in api coverage test, which is generated based on `resources_all.csv` and `resources_whitelist.csv`
dd3d069
to
e59e43b
Compare
New changes are detected. LGTM label has been removed. |
026f658
to
934cb31
Compare
934cb31
to
cb43d50
Compare
/test pull-kubernetes-verify |
From a test infra perspective, the value from verifying existence of API CRUD operations doesn't match the effort of hand-crafting object yaml files that exercise API validation. Nevertheless, we should think about having better documentation & examples in our OpenAPI models and verbs. Ref #34743, https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/ From conformance perspective, we should focus on testing the correct API behavior on pluggable parts of the system, and increasing coverage with those tests. Ref kubernetes/test-infra#5446 (comment) Closing |
What this PR does / why we need it:
Use dynamic client to simply test CRUD operations on all expected resources. Most of the YAML files are collected from kubernetes code base and kubernetes.io. Currently the test covers 406 operations (test/e2e/testing-manifests/apiresource/resources.csv) out of 702 operations (test/e2e/testing-manifests/apiresource/resources_all.csv).
The csv files are in the format of
group, version, resource, namespaced, verb
. The remaining resources are not tested yet because either the yaml file is missing, or the resource is non-namespaced and may break e2e test. Ref test/e2e/testing-manifests/apiresource/README.md for more information.Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Ref kubernetes/test-infra#5446
Special notes for your reviewer:
Release note:
/sig api-machinery
cc @erictune