-
Notifications
You must be signed in to change notification settings - Fork 228
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
[WaitForPodsReady] Make requeue base delay confiurable #2040
[WaitForPodsReady] Make requeue base delay confiurable #2040
Conversation
Skipping CI for Draft Pull Request. |
✅ Deploy Preview for kubernetes-sigs-kueue canceled.
|
/test all |
d2d1bc7
to
2f83e04
Compare
/assign @tenzen-y |
// | ||
// Defaults to 10. | ||
// +optional | ||
BaseDelaySeconds *int32 `json:"baseDelaySeconds,omitempty"` |
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 yet wondering about making the exponent and jitter configurable, wdyt @alculquicondor @tenzen-y?
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 prefer to keep this simple, but @mimowo and/or @alculquicondor have requests from your customers or you have concrete use cases, I'm ok with implementing them.
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.
Definitely not the jitter. But I'm also ok leaving the exponent out for now.
e739b55
to
1643b2d
Compare
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.
Basically, lgtm
Also could you implement validations here:
kueue/pkg/config/validation.go
Line 60 in 92baacd
func validateWaitForPodsReady(c *configapi.Configuration) field.ErrorList { |
Added, thanks |
func SetupControllers(mgr ctrl.Manager, qManager *queue.Manager, cc *cache.Cache, cfg *configapi.Configuration, controllerOpts ...ControllerOption) (string, error) { | ||
func SetupControllers(mgr ctrl.Manager, qManager *queue.Manager, cc *cache.Cache, cfg *configapi.Configuration) (string, error) { |
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 personally like the Options
pattern better.
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.
Right, but the new parameter is not needed any longer since the configuration is not passed in cfg *configapi.Configuration
. I guess we could replace cfg *configapi.Configuration
with Options
, but it would be a lot of changes, so I wouldn't like to mix this into 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.
for now changing WithControllerRequeuingBaseDelaySeconds
to something like WithControllerRequeuingBackoffBaseSeconds
can work and we can do a clean-up to drop the cfg usage.
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 see that, but the interim state of passing the params which are part of the cfg both ways would look weird. I'm happy to open a dedicated issue to do the refactoring at once.
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 we agree we should go towards Options
, why start with a step back?
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.
It's not needed as a result of this PR implementation.
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.
Again, going the path of keeping it requires more changes. I don't think refactoring of this function is a priority right now. So we should leave the code in a state that makes sense for the mid-term.
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.
going the path of keeping it requires more changes
I'm not convinced, we used to have for now changing WithControllerRequeuingBaseDelaySeconds
we can just replace it with WithControllerRequeuingBackoffBaseSeconds
.
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.
But then we have the same information flowing through cfg
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.
Let me put the context of the reason why we added the controllerOpts
.
We introduced the controllerOpts
in #2025 instead of Config API to cherry-pick to the release v0.6 as an interim approach. Then, we try to remove the interim approach in this PR.
I agree with refactoring this function, but as @alculquicondor and @mimowo, I also think that the refactoring is beyond this PR responsibility.
So, I agree with leaving the refactoring in another PR.
pkg/controller/core/core.go
Outdated
} | ||
for _, opt := range controllerOpts { | ||
opt(&ctrlOpts) | ||
} | ||
|
||
if err := NewWorkloadReconciler(mgr.GetClient(), qManager, cc, | ||
mgr.GetEventRecorderFor(constants.WorkloadControllerName), | ||
WithWorkloadUpdateWatchers(qRec, cqRec), | ||
WithPodsReadyTimeout(podsReadyTimeout(cfg)), |
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.
Maybe it would be worth something like:
WithPodsReadyTimeout(cfg.WaitForPodsReady)
So we don't need to keep adding options for every single field.
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
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.
Good idea, I just pushed a commit along the lines, but I use:
WithWaitForPodsReady(waitForPodsReady(cfg.WaitForPodsReady)),
because the controller needs the entire config. Also I use the waitForPodsReady
function to convert the underlying config into a structure easier to consume. In particular, I don't need the enable
field.
@mimowo Also, could you open another PR to update the document? |
Sure, I will follow up on this. |
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.
Thank you!
/lgtm
LGTM label has been added. Git tree hash: 27145d6920748a7c15ef5d1b55a9fd434e10e386
|
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mimowo, tenzen-y 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 |
/test pull-kueue-build-image-main |
What type of PR is this?
/kind feature
What this PR does / why we need it:
Which issue(s) this PR fixes:
Part of #2009
Special notes for your reviewer:
I'm yet wondering about making the exponent and jitter configurable, wdyt?
Does this PR introduce a user-facing change?