When the leader election is enabled, set true in leaderElectionReleaseOnCancel

[tenzen-y]

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

When the manager is terminated, the leader role replica should voluntarily steps down from its own leader role
so that backup role can take the leader role as soon as possible.

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Fix a bug that could delay the election of a new leader in the Kueue with multiple replicas env.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: 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:

• OWNERS [tenzen-y]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[netlify]

✅ Deploy Preview for kubernetes-sigs-kueue ready!

Name	Link
🔨 Latest commit	d72a0a6
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-sigs-kueue/deploys/66eb5b7729aa050008a70135
😎 Deploy Preview	https://deploy-preview-3093--kubernetes-sigs-kueue.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[tenzen-y]

/assign @trasc

[trasc]

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: cc9935ea750033752c1bf2f2271219fe3d0ff750

[mimowo]

When the manager is terminated, the leader role replica should voluntarily steps down from its own leader role
so that backup role can take the leader role as soon as possible.

If we didn't do that it feels like a bug more than just cleanup. Do you know how much delay it was causing? Maybe we could consider this for cherry-picking. WDYT @tenzen-y ?

[tenzen-y]

When the manager is terminated, the leader role replica should voluntarily steps down from its own leader role
so that backup role can take the leader role as soon as possible.

If we didn't do that it feels like a bug more than just cleanup. Do you know how much delay it was causing? Maybe we could consider this for cherry-picking. WDYT @tenzen-y ?

Goog point.

I'm not sure how much exactly time the backup replica take the leader when the primary manager is terminated.
But, the default lease renew duration is 10 sec. So, it seems that missing leader situation could happen 10sec at a max.

https://github.com/kubernetes-sigs/controller-runtime/blob/62834f93955d634d84c64159e09a54897c6b7c21/pkg/manager/manager.go#L215-L217

I guess that the situation could happen when the primary manager takes a long time to graceful terminate cache and scheduler, and all Kueue internal components.

[tenzen-y]

So, I think that cherry-picking this to release-0.8 could bring production env more stability.

[tenzen-y]

/remove-kind-cleanup

[tenzen-y]

/kind bug

[tenzen-y]

/remove-kind cleanup

[tenzen-y]

/release-note-edit

Fix a bug that could delay the election of a new leader in the Kueue with multiple replicas env.

[tenzen-y]

/cherry-pick release-0.8

[k8s-infra-cherrypick-robot]

@tenzen-y: new pull request created: #3096

In response to this:

/cherry-pick release-0.8

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-sigs/prow repository.