-
Notifications
You must be signed in to change notification settings - Fork 159
[WIP] Gke integration tests #319
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
[WIP] Gke integration tests #319
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: hantaowang 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 |
Hi @hantaowang. Thanks for your PR. I'm waiting for a kubernetes-sigs or kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
8a4e02b
to
c26d342
Compare
/ok-to-test |
c26d342
to
7be1b1d
Compare
7be1b1d
to
ec898fb
Compare
325d779
to
2a91a29
Compare
/assign @davidz627 |
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.
Thanks for going above and beyond and coming up with ways to speed up the testing infra. However, unless we are able to abstract away the dependency chain blocking and error channel handling I don't think we'll be able to merge this as is.
The main concern I have is "what if I need to add an extra step in the integration test process, how many separate pieces of code not related to my own function do I need to change and how easy it is to shoot myself in the foot".
I think there is probably a way to abstract away these things with contexts and wait groups but no obvious elegant solution immediately comes to mind.
It looks like several non-related improvements were made in the same PR. In general that will slow down the entire PR (if there is an issue/concern with one improvement it will block all other changes from getting in). Small, targeted PRs are your friend. This monolith could be broken down into:
- Flag handling improvements PR
- Split functions to files PR
- Parallelism PR
- New flags/functionality for testing version PR
In that way I think all but the parallelism PR would be no-brainers to merge, we could move forward with other things and bikeshed/work on the parallelism PR to our hearts content.
defer removeTempDir(k8sParentDir) | ||
defer removeTempDir(testParentDir) | ||
|
||
numTasks := 4 |
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.
Can it be a const
? Why is the numTasks=4, could probably use a comment
if len(*testVersion) != 0 && *testVersion != *kubeVersion { | ||
go func() { | ||
// TODO: Build only the tests | ||
err := downloadKubernetesSource(pkgDir, testParentDir, *testVersion) |
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.
can we download only one version of the source and just copy it if we need it for test dir
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.
I think it makes it a lot more complicated dependency wise, so I'll think about it.
// Otherwise, either kube version is set (which implies GCE) or a local K8s dir is being used | ||
if len(*testVersion) != 0 && *testVersion != *kubeVersion { | ||
go func() { | ||
// TODO: Build only the tests |
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.
make WHAT=test/e2e/e2e.test
}() | ||
} else { | ||
testDir = k8sDir | ||
errChan <- 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.
kind of odd to me that we need to push nil errors onto the errChan
like this. Feel like we should be able to have something watch the errChan
for any actual errors and halt the entire test suite (and execute all defers for cleanup).
Maybe something like a watcher that watches the error channel that pushes a cancel signal to a context that all goroutines take in. Let me know if this would make it more complicated, but I feel like it's more extensible so we don't have to do an error prone counting of errChan signals as we add/remove things from the integration testing
|
||
numTasks := 4 | ||
errChan := make(chan error, numTasks) | ||
k8sDependencyChan := make(chan bool, 1) |
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.
can we use named waitgroups to capture dependency chains where certain operations have to wait for groups of other operations to complete before we can proceed.
I'll let this PR sit for now, but I've already moved some of the small changes into other PRs. See #322 for the utility changes and #323 for the test-version flag related changes. When those are merged I will open a PR to break apart the huge |
@hantaowang: 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. |
/close |
@hantaowang: 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 clarifies versioning with the deployment strategies gce and gke.
It also cleans up some code with the
ensureVariable
,ensureFlag
,getTempDir
,removeTempDir
helper functions.It also makes certain time consuming tasks run concurrently. Tell me if this is not desired.