-
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
Set default leader election configuration #1598
Conversation
✅ Deploy Preview for kubernetes-sigs-kueue canceled.
|
Hi @astefanutti. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
/ok-to-test |
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 overall
pkg/config/config_test.go
Outdated
LeaderElection: true, | ||
LeaderElectionID: configapi.DefaultLeaderElectionID, | ||
LeaderElectionResourceLock: resourcelock.LeasesResourceLock, | ||
LeaseDuration: ptr.To(15 * time.Second), |
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 instead of the magic values refer to values in defaultControlOption
, so that is easier to identify which fields deviate from defaults?
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. Updated.
if len(cfg.LeaderElection.ResourceLock) == 0 { | ||
// Default to Lease as component-base still defaults to endpoint resources | ||
// until core components migrate to using Leases. See k/k #80289 for more details. | ||
cfg.LeaderElection.ResourceLock = resourcelock.LeasesResourceLock |
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.
Is this a change compared to what is happening on the main branch? I'm wondering if this deserves a release note explaining what are the user-facing differences when using defaults.
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.
No, it doesn't change the default value compared to main. It's necessary so we can delegate to RecommendedDefaultLeaderElectionConfiguration
, but that still defaults to endpoints as resource lock, because some Kubernetes components haven't migrated yet, and maintain the current default value for Kueue.
This can be removed once kubernetes/kubernetes#80289 is fixed.
cfg.LeaderElection.ResourceLock = resourcelock.LeasesResourceLock | ||
} | ||
// Use the default LeaderElectionConfiguration options | ||
configv1alpha1.RecommendedDefaultLeaderElectionConfiguration(cfg.LeaderElection) |
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.
As before, question about user-facing consequences of setting the defaults.
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.
With the values already set in the default Kueue configuration, i.e.:
kueue/config/components/manager/controller_manager_config.yaml
Lines 10 to 12 in d4d3f3b
leaderElection: | |
leaderElect: true | |
resourceName: c1f6bfd2.kueue.x-k8s.io |
That PR is "idem-potent".
The only change would be if an existing user would use a configuration with .leaderElection
or .leaderElection.leaderElect
not defined, then the new default would be true, instead of false.
But I'd be inclined to think enabling leader election by default is desirable.
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.
How about the values of LeaseDuration
, RenewDeadline
, RetryPeriod
, as the values are now generated, are they ignored, or their values are as implicit defaults used before?
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.
Yes, the latter, their values are equal to the implicit defaults used before.
@@ -43,13 +44,6 @@ const ( | |||
DefaultClusterQueuesMaxCount int32 = 10 | |||
) | |||
|
|||
func addDefaultingFuncs(scheme *runtime.Scheme) 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.
nice win
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
/assign @tenzen-y @alculquicondor
LGTM label has been added. Git tree hash: d17270b277bc93330482b2f483ade14d255eea37
|
/release-note-edit
|
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alculquicondor, astefanutti 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 |
/kind api-change |
What type of PR is this?
/kind feature
What this PR does / why we need it:
The leader election section of the Kueue configuration is not defaulted.
Kubernetes components, like the scheduler, usually delegate to component-base to set sensible defaults:
https://github.com/kubernetes/component-base/blob/d5ddea0e47af10468dcd90e09768b2661caf23f7/config/v1alpha1/defaults.go#L35
Implementing that recommended defaulting has been suggested in the following discussion: #1554 (comment).
Does this PR introduce a user-facing change?