-
Notifications
You must be signed in to change notification settings - Fork 276
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
Propagate gomega.Gomega. #3347
Propagate gomega.Gomega. #3347
Conversation
✅ Deploy Preview for kubernetes-sigs-kueue canceled.
|
/cc @mimowo |
@@ -680,12 +662,22 @@ func ExpectPodsFinalized(ctx context.Context, k8sClient client.Client, keys ...t | |||
for _, key := range keys { | |||
createdPod := &corev1.Pod{} | |||
gomega.EventuallyWithOffset(1, func(g gomega.Gomega) { | |||
g.Expect(k8sClient.Get(ctx, key, createdPod)).To(gomega.Succeed()) | |||
g.Expect(client.IgnoreNotFound(k8sClient.Get(ctx, key, createdPod))).To(gomega.Succeed()) |
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.
Why changing this? This is changing the semantics of the assert, maybe we want to check the pod still exists. Should we have 2 functions: ExpectPodsGoneOrFinalized
(deleted or no finalizers) and ExpectPodsFinalized
(no finalizers). Maybe both functions make sense depending on the context?
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.
If the pod is finalized, then we can delete it. I think this might have been missed.
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.
Hm, but actually as long as the owner workload exists the pod is expected not to be deleted, even if it already does not have the finalizers. So, asserting the set of finalizers (without checking if the pod is gone) seems to make sense.
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.
Ah, no, the relationship is another way round - pod owns the workload. In that case indeed it might be GC-ed. So, better to check ExpectPodsFinalizedOrGone
2f64ca1
to
7215f00
Compare
/hold |
8d4018c
to
f5b6fc5
Compare
f5b6fc5
to
3d94699
Compare
ed71fac
to
08fd136
Compare
/unhold |
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
/approve
Thanks!
LGTM label has been added. Git tree hash: 6603d827dd1bed03f94f11e6849fcf8de3cbbac9
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mbobrovskyi, mimowo The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/lgtm |
LGTM label has been added. Git tree hash: 1e0f933bcf97013e78f2e95907ba4bc86d8b7534
|
* Propagate gomega.Gomega. * Renamed ExpectPodsFinalized to ExpectPodsFinalizedOrGone. * Fix "should allow to schedule a group of diverse pods" test. * Add ExpectPodsJustFinalized. * Fixed flaky "should allow to schedule a group of diverse pods" test.
* Propagate gomega.Gomega. * Renamed ExpectPodsFinalized to ExpectPodsFinalizedOrGone. * Fix "should allow to schedule a group of diverse pods" test. * Add ExpectPodsJustFinalized. * Fixed flaky "should allow to schedule a group of diverse pods" test.
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Propagate gomega.Gomega.
Which issue(s) this PR fixes:
Fixes #3300
Special notes for your reviewer:
Does this PR introduce a user-facing change?