-
Notifications
You must be signed in to change notification settings - Fork 38.7k
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
[Federation] Add type-agnostic e2e crud test #43194
[Federation] Add type-agnostic e2e crud test #43194
Conversation
96a994b
to
78676f6
Compare
@nikhiljindal assigning it to you because you are reviewing other integration test PRs and have better context about it. |
cc: @perotinus |
@@ -31,7 +31,7 @@ import ( | |||
) | |||
|
|||
type SecretAdapter struct { | |||
client federationclientset.Interface | |||
Client federationclientset.Interface |
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.
Does this need to be public? You could add a NewSecretAdapter method instead.
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 there a reason to choose one approach over another? I've generally preferred to use factory methods only when more than simple assignment is required.
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 looks good overall. I do question whether the CRUDHelper should be in a separate package that is depended on by both integration and e2e tests: it seems more like a generic testing harness than something directly tied to either kind of test.
@perotinus I agree that CRUDHelper should be separated, if only because otherwise any e2e using it will be pulling in everything needed to run federation and kubernetes api servers. I think having it live in something like |
@marun Yes, that's kind of what I had in mind too. I think your idea of package structure is reasonable for now. I'm not familiar enough with the test tree to really know of a better place, though I could see either a federation subdir This LGTM. |
78676f6
to
c8d0cbf
Compare
5ead989
to
1e55903
Compare
I've rebased this on top of #43500 to benefit from the refactoring it did, and switched to adding a new test instead of replacing the old one. My intent is to reduce the risk of losing coverage while the kinks in this approach are worked out. |
438b33f
to
48caf3d
Compare
test/e2e_federation/crud.go
Outdated
It("should be created, read, updated and deleted successfully", func() { | ||
fedframework.SkipUnlessFederated(f.ClientSet) | ||
|
||
// Only need to load clients once |
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.
Why do you need to do this in the test block? Will GetClusterClients not work in the outer scope?
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.
Getting the cluster clients is an expensive operation. No point in doing it if the test will be skipped.
27a3e09
to
06675be
Compare
LGTM. |
@csbell @nikhiljindal @madhusudancs Can someone else approve this? |
06675be
to
907e59e
Compare
42be96b
to
8180ac8
Compare
@k8s-bot pull-kubernetes-federation-e2e-gce test this |
8180ac8
to
2470a71
Compare
@k8s-bot bazel test this |
2470a71
to
d979210
Compare
rebased @k8s-bot pull-kubernetes-federation-e2e-gce test this |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: csbell, marun
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
Automatic merge from submit-queue (batch tested with PRs 44519, 43194, 44513) |
@marun: The following test(s) failed:
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. |
This PR proposes an e2e test that reuses the type-agnostic crudtester already used for integration testing to validate crud against a deployed cluster. It is intended to to eventually replace the existing e2e tests for simple types like secrets, but for now will run in addition to the existing testing to gain confidence in the coverage it provides.
The deletion corner cases - when orphanDependents is nil or true - do not involve operations in the member clusters and are already well-tested in integration testing and so are not reimplemented here.
Where it can be applied, this approach of abstracting a test from its execution environment - making the test 'retargetable' - can reduce the cost of test development since the bulk of the work can be iterated on as an integration test. It can also serve as a check on assumptions made in the integration test about how a deployed environment will behave.
cc: @kubernetes/sig-federation-pr-reviews @kubernetes/sig-testing-misc @smarterclayton @derekwaynecarr