-
Notifications
You must be signed in to change notification settings - Fork 58
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
🌱 fix(e2e): wait for leader election #1676
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -40,6 +40,17 @@ func TestClusterExtensionAfterOLMUpgrade(t *testing.T) { | |
t.Log("Wait for operator-controller deployment to be ready") | ||
managerPod := waitForDeployment(t, ctx, "operator-controller-controller-manager") | ||
|
||
t.Log("Wait for acquired leader election") | ||
// Average case is under 1 minute but in the worst case: (previous leader crashed) | ||
// we could have LeaseDuration (137s) + RetryPeriod (26s) +/- 163s | ||
leaderCtx, leaderCancel := context.WithTimeout(ctx, 3*time.Minute) | ||
defer leaderCancel() | ||
|
||
leaderSubstrings := []string{"successfully acquired lease"} | ||
leaderElected, err := watchPodLogsForSubstring(leaderCtx, managerPod, "manager", leaderSubstrings...) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Scraping the logs seems brittle. Would it be better to use a Watch on the leader election? We could use the Leases from CoordinationV1Client from "k8s.io/client-go/kubernetes/typed/coordination/v1" ? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I realize it's also longer and more code, but the upside is it reacts right away, like watching for the pod log, but without caring if strings change at some point, and break our tests out of our control. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. that's a good idea! If this work is blocking CI, I'd say merge it as it is, then follow up with the watch ^^ There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, I agree that we could do something more fancy |
||
require.NoError(t, err) | ||
require.True(t, leaderElected) | ||
|
||
t.Log("Reading logs to make sure that ClusterExtension was reconciled by operator-controller before we update it") | ||
// Make sure that after we upgrade OLM itself we can still reconcile old objects without any changes | ||
logCtx, cancel := context.WithTimeout(ctx, time.Minute) | ||
|
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 am assuming 3 minutes is the worst case scenario. I am not familiar with
context.WithTimeout
, does it return if we acquire the lease before 163s?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.
context.WithTimeout
just gives you a context that timesout (gets cancelled) after then timeout period.This means that the call to
watchPodLogsForSubstring(leaderCtx, managerPod, "manager", leaderSubstrings...)
will return with an error if it hasn't already after 3 minutes.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.
ok, looks like it is a straight forward timeout method.