-
Notifications
You must be signed in to change notification settings - Fork 41.5k
DRA: CRUD conformance tests #133747
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
DRA: CRUD conformance tests #133747
Conversation
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The 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-sigs/prow repository. |
/test pull-kubernetes-audit-kind-conformance DeleteCollection not implemented yet, checking whether the job finds that... |
f28bd30
to
eb603fc
Compare
/test pull-kubernetes-audit-kind-conformance Now with DeleteCollection, non-namespace list and API get. |
/test pull-kubernetes-e2e-kind |
/retest |
2500c4d
to
8093062
Compare
It's a nested map which looks a lot nicer as YAML, in particular when it represents a Kubernetes object. Unit+integration tests using ktesting+gomega and E2E tests benefit from this change.
That was the original intent, but the implementation then ended up checking ResourceClaims in all namespaces. Depending on timing this was merely misleading (showing ResourceClaim changes from a different test running in parallel), but with upcoming CRUD tests which intentionally set an allocation result without a finalizer it breaks the non-CRUD tests when they check the those CRUD ResourceClaims.
8093062
to
d9df6f8
Compare
I had to rebase to get access to The actual changes are in https://github.com/kubernetes/kubernetes/compare/2500c4d0c2811b6be8ac9a2ea5f2f43e5b1e33b2..8093062d4cc36bd8dc3be4c6e44ef13a2b667ec3:
Small cleanups in https://github.com/kubernetes/kubernetes/compare/8093062d4cc36bd8dc3be4c6e44ef13a2b667ec3..d9df6f82a77e659855720ea6f4be01967e2874f3 |
Promoting real tests turned out to be harder than expected (should be rewritten to be self-contained, additional reviews, etc.). They would not achieve 100% endpoint+operation coverage because real tests only use some of the operations. Therefore each API type has to be covered with CRUD-style tests which only exercise the apiserver, then maybe additional functional tests can be added later (depending on time and motivation). The machinery for testing different API types is meant to be reusable, so it gets added in the new e2e/framework/conformance helper package.
d9df6f8
to
f95d531
Compare
/test pull-kubernetes-unit /test pull-kubernetes-node-e2e-containerd-2-0-dra-alpha-beta-features pull-kubernetes-e2e-gce Cluster resp. machine didn't come up. I know that Ben wants me to investigate this because someone has to, but I don't have the time right now to learn about that stuff... 😬 |
I think there are probably opportunities to simplify the framework a little to make it easier to follow (and if we want to do that we should make tweaks before this attracts a bunch of other callers and starts getting promoted into actual conformance), but I'm very happy with the current state of what this is testing. It represents the best practices we know of from other conformance tests (tolerate non-instantanous deletes with finalizers, use robust informer-driven checks of watch event invariants, etc). /lgtm |
LGTM label has been added. Git tree hash: 0611c95f523a99f462b9118ca4a0127e4d12ca65
|
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.
Agree to merge and iterate from here, I think there's room to make this even slightly more guarded against misuse and simplify a bit but overall I think this will be a big improvement over hand-writing this style of test
/lgtm
/approve
}, | ||
}, | ||
UpdateSpec: func(obj *resourceapi.DeviceClass) *resourceapi.DeviceClass { | ||
obj.Spec.Selectors[0].CEL.Expression = "1 == 0" // Still matches no devices. |
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 should not be enabled in conformance tests because admission | ||
// is allowed to modify what is being stored. | ||
ContentVerificationEnabled bool |
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.
Seems like there's room to validate this struct, e.g. checking that if this bool is set then StrategicMergePatchSpec needs to be set if UpdateSpec is set?
I like what we're doing here overall, but it seems like if you don't copy-paste from another test, it might be easy to use incorrectly, even though it's still easier than writing these from scratch.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: BenTheElder, liggitt, pohly 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 |
fyi @serathius /retest |
The integration failure is The e2e is :
|
/retest |
hmmm, is the failure any conflict with the DRA resources created by this test? |
The Kubernetes project has merge-blocking tests that are currently too flaky to consistently pass. This bot retests PRs for certain kubernetes repos according to the following rules:
You can:
/retest |
Doesn't seem likely. Each DRA test uses a unique driver name and the objects created by these new tests shouldn't interfere with any concurrently running test. Let's keep an eye open for it though before promoting the new tests. Speaking of which, that promotion is in #134439, pending for now until the tests have enough soak time. |
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Promoting real tests (#133132) turned out to be harder than expected (should be rewritten to be self-contained, additional reviews, etc.).
They would not achieve 100% endpoint+operation coverage because real tests only use some of the operations. Therefore each API type has to be covered with CRUD-style tests which only exercise the apiserver, then maybe additional functional tests can be added later (depending on time and motivation).
Which issue(s) this PR is related to:
#114183
#133691
KEP: kubernetes/enhancements#4381
Special notes for your reviewer:
The machinery for testing different API types is meant to be reusable, so it gets added in the new e2e/framework/conformance helper package.
Does this PR introduce a user-facing change?