-
Notifications
You must be signed in to change notification settings - Fork 81
Enable the VolumeGroupSnapshot tests #283
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
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: Penghao <[email protected]>
d0ea3ee to
9fb036e
Compare
|
/test pull-kubernetes-csi-release-tools-csi-test |
|
Hi @xing-yang @jsafrane @gnufied @msau42 , could you please help review when you get a chance? Thank you! |
|
/assign @xing-yang @jsafrane @gnufied @msau42 |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Phaow 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 |
|
/label tide/merge-method-squash |
a1ecfa1 to
5005ced
Compare
|
Hi @jsafrane , could you help take a look again when you get a chance? Thank you! I hack some codes in master...Phaow:csi-release-tools:dev and verify it works, which needs update in job definition part, the script also needs the https://github.com/kubernetes-csi/csi-release-tools/blob/master/filter-junit.go, I will download it in prow job definition part. |
Signed-off-by: Penghao <[email protected]>
5005ced to
9160d31
Compare
|
/test pull-kubernetes-csi-release-tools-external-provisioner |
1 similar comment
|
/test pull-kubernetes-csi-release-tools-external-provisioner |
prow.sh
Outdated
| vgs) | ||
| # VGS tests are in in-tree/core tests; do NOT pass -storage.testdriver | ||
| ginkgo_target="${CSI_PROW_WORK}/e2e.test" | ||
| cd "${e2e_src_dir}" || die "cd ${e2e_src_dir} failed" | ||
| ;; |
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 admit I don't understand why there is vgs as a special value. IMHO the VGS tests don't change how junit fiels a re generated / moved or what binaries to run.
Please correct me if I am wrong. There were two kinds of tests:
local, running "e2e-local.test", if available- non-
local, running "e2e.test -storage.testdriver=test-driver.yaml" with csi-driver-hostpath with CSI sidecars either compiled from a PR or canary or whatever.
Now you want to add a new set of tests
e2e.testwith in-tree tests, that have all sidecars hardcoded in Kubernetes manifests, only with optional "--feature-gate=CSIVolumeGroupSnapshot=true" in its external-snapshotter (see Refine: VolumeGroupSnapshot tests kubernetes/kubernetes#134214). Should we call itin-tree? And focus not justFeature:volumegroupsnapshot, but all[Driver: csi-hostpath]
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.
Now that I am reading what I wrote, should the in-tree tests use all sidecars from the PR they run in? Or even canary? That would be definitely for a future improvement, not this PR.
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.
non-local, running "e2e.test -storage.testdriver=test-driver.yaml" with csi-driver-hostpath with CSI sidecars either compiled from a PR or canary or whatever.
It seems currently only snapshot controller image could used the one compile from the PR, the snapshotter and other sidecar images do not override for hostpath csi driver->https://github.com/kubernetes-csi/csi-release-tools/blob/master/prow.sh#L720-L769 .
should the in-tree tests use all sidecars from the PR they run in?
From my understanding, we'd better keep this part in the prow.sh with external CSI testsuite, which we could replace the hostpath sidecar images directly.
To run vgs test toward external hostpath csi driver we still needs hack 90b69e4#diff-c2d96beb8cf73c62f7ae059aff96e381a8d73317df3ce356f36ba6b46338959dR784-R804 and kubernetes/kubernetes#134633.
So maybe we'd better choose to use the external hostpath csi driver for sidecars tests, right?
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.
should the in-tree tests use all sidecars from the PR they run in?
From my understanding, we'd better keep this part in the prow.sh with external CSI testsuite, which we could replace the hostpath sidecar images directly.
Yes, that's what I think too. But this PR adds vgs tests that will test with csi-driver-hospath yaml files hardcoded in k/k. It would be better to run them with the hostpath driver installed in prow.sh.
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.
Change to run vgs tests from csi external and integration with k/k PR works as expected.
Signed-off-by: Penghao <[email protected]>
Signed-off-by: Penghao <[email protected]>
|
@Phaow Sorry if you answered this already, but why aren't we implementing this via - https://github.com/kubernetes-csi/external-snapshotter/blob/master/.prow.sh ? Is that not doable? |
|
Hi @gnufied , thanks for looking into this, we have a discussion try to use it also for k/k vgs testing -> |
Signed-off-by: Penghao <[email protected]>
Signed-off-by: Penghao <[email protected]>
| # | ||
| # This can be used as an example post-install hook by setting: | ||
| # export CSI_PROW_DRIVER_POSTINSTALL="vgs_post_install" | ||
| vgs_post_install () { |
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.
Where is this being called from? Did you mean to keep this as an example and then have it actually in external-snapshotter repo or did you mean to call this function inline?
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 expect call this inline for k/k storage kind jobs just declare the env CSI_PROW_DRIVER_POSTINSTALL="vgs_post_install" in https://github.com/kubernetes/test-infra/pull/35680/files#diff-5ca5c1a86ebcf3b5a8105d06bf3010fe3b0f8d4b3093cf4668d84389e3bea3e3R340 . Actually in external-snapshotter repo we could reuse the inline function, in k/k we do not add the release tool subtree, if we want to reuse it we have to make it inline(k/k could not reuse the post_install from external sidecar repos directly unless we also clone/copy it from sidecar). Not sure I missed something, any better ideas are welcome ^^
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.
Not sure I missed something, any better ideas are welcome ^^
I meant if you intend to use this function, then it should be assigned to CSI_PROW_DRIVER_POSTINSTALL variable or if you intend this to be used from external-snapshotter repo, then this function should be moved to .prow.sh of that repository.
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.
With respect to vgs I intend to use this function, yeah it should be assigned to CSI_PROW_DRIVER_POSTINSTALL variable in job configuration. It could be used for both external-snapshotter and k/k vgs jobs.
Signed-off-by: Penghao <[email protected]>
|
Hi @gnufied , could you help take a look again when you get a chance? Thank you! ^^ |
|
/lgtm |
|
Hi @jsafrane , could you help take a review again when you get a chance? Thank you! ^^ |
What type of PR is this?
/kind test
What this PR does / why we need it:
Used the temporary job for vgs
pull-kubernetes-e2e-storage-kind-vgsverified it works as expected in live PR.Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?: