-
Notifications
You must be signed in to change notification settings - Fork 169
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
Wrap K8s client in E2E with retry logic #3366
Wrap K8s client in E2E with retry logic #3366
Conversation
99a8cf1
to
c03370a
Compare
test/e2e/helpers.go
Outdated
var ( | ||
DefaultTimeout = 5 * time.Second | ||
PollingInterval = 250 * time.Millisecond | ||
) |
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.
Unclear to me at this point what these numbers should be and if we should expose them in the API for users to mess with
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 like this approach!
Re: your concern about where/when to bump the dependency, I don't see any problem with doing it in the same PR as this work. I think that's typically what we do unless it's an especially scary/large set of dependency bumps.
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'm a big fan of this approach and implementation, I love the usage of generics here.
I'm in favor of having this PR, if acceptable to the wider team, merge as-is, and to make the effort of rolling this out across all our E2E tests the work of future stories, that are spread across the team. It'd be slower, but it would get more people involved in the change to hopefully normalize this approach across future tests as well.
I like this approach but I would suggest that splitting the work by client would be a more natural division. I can expand this PR to cover the k8s client and version bump and then people could pick up each of the other clients? What do you think? (I actually have a second proposal that builds on this concept that I thought would be useful to spread around for the same reasons you outline but I think you're right and we can start introducing it from here) |
I think that works too, my goal is to split work on this across the team, whichever way we split it is fine by me as long as it gets enough eyes on the change. |
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.
👍🏼
@@ -1,90 +0,0 @@ | |||
package project |
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 was only being used by cluster.go
so I just co-located it.
Please rebase pull request. |
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.
LGTM - one minor nit but it's not a blocker
/azp rerun e2e |
Command 'rerun' is not supported by Azure Pipelines. Supported commands
See additional documentation. |
/azp run e2e |
Azure Pipelines successfully started running 1 pipeline(s). |
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.
LGTM. Thank you for this @mociarain. This is a good improvement.
I just left some optional suggestion in case you find any useful.
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.
LGTM. Thanks!
Marking this PR as high priority - I believe this change will go a long way towards fixing known flakes and currently-broken e2e tests such as the one being debugged in #3384 |
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 a lot! I left one comment over on the other PR, it's more of a question, but we can get this merged now to help resolve e2e failures. #3388 (comment)
Which issue this PR addresses:
Fixes https://issues.redhat.com/browse/ARO-4489#L67 and
What this PR does / why we need it:
This PR addresses the first part of initiative 1 outlined here.
TODO:
(Assuming the approach is okay'd) Start another PR/PR's for the other clients.Not doing. See here for details.Ideally, I would do this here as part of this PR. Is bumping the version of a dependency a big deal? AFAIK it's used (nearly) entirely in the E2E tests so I'm hoping it will be smooth.Will do in a subsequent PR. This one is meaty enough.Test plan for issue:
Run them all.
Is there any documentation that needs to be updated for this PR?
Very possibly