Bug 2037075: Verify Builds with CSI Volume Sources#26646
Bug 2037075: Verify Builds with CSI Volume Sources#26646openshift-merge-robot merged 1 commit intoopenshift:masterfrom
Conversation
There was a problem hiding this comment.
Please note that this image is being relocated for multi-arch support in #26598
098e68a to
3f945c1
Compare
|
you have to update the bindata @jkhelil ... that appears to be what the verify failure is complaining about you also minimally have to assign @adambkaplan to this PR to get teh approved label per #26646 (comment) |
gabemontero
left a comment
There was a problem hiding this comment.
I'm guessing the ginkgo code of the e2e's is just following the pattern @coreydaley established with his original build volume work
assign this PR to him as well so he can review these
otherwise I added some shared resource specific comments, along with a question to @adambkaplan that might mean a tweak to what you are doing in your OCM PR
| csi: | ||
| driver: csi.sharedresource.openshift.io | ||
| volumeAttributes: | ||
| sharedSecret: my-secret |
There was a problem hiding this comment.
Per my comment to you in https://docs.google.com/document/d/1F3VFkiLUJbsUkFJcjnA2oyROYTI5RRlTJYl4ZWQoNls/edit?disco=AAAASUDEeYE add the `‘refreshResource’ attribute, and set it to a string value of false
There was a problem hiding this comment.
Another option as well, which I might like better, is that in your OCM controller PR, if you see CSI driver volume mounts with our shared resource driver here, you adjust their volume attributes to force refreshResources to 'false'
WDYT @adambkaplan
There was a problem hiding this comment.
@gabemontero I added the refreshResource attribute
There was a problem hiding this comment.
OK putting a comment to reflect our team discussion yesterday on this after I posted my last set of comments, namely
we are NOT going to have the OCM force shared resource CSI volumes to have refreshResource set to false.
That said, it is a supported option we do want to let user opt into.
So I'll need to adjust my request to you here @jkhelil ..... for each of your shared resource test items here, have one where you do not set refreshResource, and then one where you add the refreshsResource: 'false' setting
There was a problem hiding this comment.
@gabemontero what is the purpose for adding tests without refreshsResource: 'false', because we know that it shouldnt happen for builds and it will fail(correct me if i am wring about it)
There was a problem hiding this comment.
no @jkhelil both scenarios should work
- if the user does not add the
refreshResourcevolume attribute, it should work - if the user does add the
refreshResourece: 'false'volume attribute, it should work
Hence, I want you to make sure both paths work but having 2 flavors of your various tests here.
There was a problem hiding this comment.
@gabemontero can you have a look please to the changes regarding this last comment
There was a problem hiding this comment.
ok I'm good with the mix you have for this @jkhelil
There was a problem hiding this comment.
git the approve label from @adambkaplan and see if @coreydaley is OK with the way you added to the volumes tests he did, and we'll go from there
also, if the agnostic-cmd test is the only failure in the tests, and if you examine the tests and provide a comment to use explaining that all the sig-builds test have passed, and none of any remaining flakes are build related, we can use the skip prow command to bypass that one
test/extended/testdata/builds/volumes/csi-sharedresourcerolebinding.yaml
Outdated
Show resolved
Hide resolved
|
/test e2e-aws-serial |
|
/test e2e-aws-single-node |
|
/assign @gabemontero /assign @coreydaley /assign @adambkaplan see if you can remember @jkhelil to start doing these assigns yourself. |
|
ack @gabemontero , I do remember, Just not clear for me if I should wait until all tests are green to assign the PR for approval or not |
|
/test e2e-gcp-upgrade |
I would say if there is more than likely chance that the failed test are non-related flakes, go ahead and assign / start the review process. |
d09498d to
d3e8990
Compare
|
/test e2e-gcp-builds |
|
/test e2e-agnostic-cmd |
|
curious the new tests pass even though we have not merged all the OCM/builder/etc. stuff yet is that expected @jkhelil ? @adambkaplan FYI |
duh @jkhelil @adambkaplan :-) ... none of the e2e's run so far were against a tech preview cluster so the tests were skipped sorry for the noise :-) |
adambkaplan
left a comment
There was a problem hiding this comment.
@jkhelil we should also have a test on a standard cluster which tries to mount a CSI volume. In this test case, we would expect the build to be created, and then later fail.
|
/retitle Bug 2037075: Verify Builds with CSI Volume Sources |
|
/test e2e-agnostic-cmd |
|
/test e2e-aws-cgroupsv2 |
|
/test e2e-aws-csi |
|
/test e2e-gcp-upgrade |
|
/assign @adambkaplan for approval |
|
@jkhelil: GitHub didn't allow me to assign the following users: for, approval. Note that only openshift members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. DetailsIn 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. |
|
/assign @adambkaplan |
|
/test e2e-agnostic-cmd |
|
bump @adambkaplan are you at least willing to apply the approve label to @jkhelil PR and have others complete the review, or do you think you'll be able to get lgtm level cycles to look at this soon. other than non related flakes in the agnostic cmd suite, this appears green |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: adambkaplan, gabemontero, jkhelil The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
1 similar comment
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
@jkhelil: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
6 similar comments
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
@jkhelil: All pull requests linked via external trackers have merged: Bugzilla bug 2037075 has been moved to the MODIFIED state. DetailsIn 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. |
https://issues.redhat.com/browse/BUILD-275