-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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 LeaderElectionReleaseOnCancel
to the scaffolded main.go
#2593
Comments
I would like to work on this. |
Questions:a) why should we use it by default? Additionally you say:
c) What errors logs? Can you please share the link? Note that by performing the following steps I cannot see any error: $ cd /testdata/project-v3
$ go mod tidy
$ go vet ./... OR By running make all to call all: r$ make all
GOBIN=/Users/camilamacedo86/go/src/sigs.k8s.io/kubebuilder/testdata/project-v3/bin go install sigs.k8s.io/controller-tools/cmd/controller-gen@v0.8.0
/Users/camilamacedo86/go/src/sigs.k8s.io/kubebuilder/testdata/project-v3/bin/controller-gen object:headerFile="hack/boilerplate.go.txt" paths="./..."
go fmt ./...
go vet ./...
go build -o bin/manager main.go
|
@camilamacedo86 Error is solved now. It was showing because I added |
Regarding (1)- As the comment mentioned, when the program is terminated immediately after the Manager is done, it yields better performance and it's safe to use (or more accurately - not "not safe" :P). Since Kubebuilder scaffolding |
Hi @AlmogBaku, By not setting the option that means use its default value. In this way, I'd like to suggest you raise it in controller runtime and begin a discussion there. IMO: Would be great we have in its docs when the option should or not be true? What are the use cases where it is recommended to use that? So after discussing this topic with controller-runtime maintainers we can understand all caveats and then contribute with additions to the doc. WDYT? Could we move forward in this way? Hi @NikhilSharmaWe, Thank you for letting us know that the problem does not exist with the default scaffolds. So, @AlmogBaku and @NikhilSharmaWe: Could we agree to close the PR (https://github.com/kubernetes-sigs/kubebuilder/pull/2596/files) as deferred, close this issue and then begin this discussion on the controller runtime if you see that fits? |
Unlike with the controller-runtime, with Kubebuilder the generated code runs the Runnables throuhgh the This is not required when using the controller-runtime, and developers can implement it however they desire (which is why it's not defaulted). Therefore - I think it should be done in Kubebuilder, and the C+R default value should remain the same. I suggest we'll talk about it in the Triage meeting. WDYT @camilamacedo86 ? |
Kubebuilder is only a tool to scaffold the files to create "controller-runtime" based projects, see; Sorry, but then I do not follow your argument. I'd suggest we begin here with:
When is a good idea or not to wait for the leaseDuration? IMO: It does not seem to be a good idea to be used by default since it can cause concurrence issues. You have 2 leaders doing the same reconciliations. |
Please inform me if there will be a meeting for this discussion, I would like to join in. |
Hi @NikhilSharmaWe we have biweekly meeting : https://docs.google.com/document/d/1Ih-2cgg1bUrLwLVTB9tADlPcVdgnuMNBGbUl4D-0TIk/edit#heading=h.dp4gt7gj3cn |
Hi, I suggest we'll discuss it in our meeting. |
Hi @AlmogBaku, Following is a summary and my vote about this one.
My understanding here is that this could result in the old and new leaders doing the same reconciliations, and because of this, it is unsafe for the common scenarios. |
The reason C+R states it's not defaulted as That being said, that's not the case for our generated |
I would worry that folks would change their main.go (which we tell them is totally allowed) such that the binary no longer exits when the manager stops. Most folks probably don't take the time to understand every default kubebuilder uses, so they'd likely leave this setting enabled despite it now being unsafe. Could we add this to the scaffold with a comment about what it is, but then leave it commented out? That way
|
I am ok with the proposed idea by @joelanford here as well. // LeaderElectionReleaseOnCancel defines if the leader should step down voluntarily
// when the Manager ends. This requires the binary to immediately end when the
// Manager is stopped, otherwise, this setting is unsafe. Setting this significantly
// speeds up voluntary leader transitions as the new leader don't have to wait
// LeaseDuration time first.
//
// In the default scaffold provided, the program ends immediately after
// the manager stops, so would be fine to enable this option. However,
// if you are doing or is intended to do any operation such as perform cleanups
// after the manager stops then its usage might be unsafe.
// LeaderElectionReleaseOnCancel: true, WDYT @AlmogBaku @NikhilSharmaWe would that be acceptable? |
+1 |
@NikhilSharmaWe, see I think we could reach a consensus here. Could you update your PR so we get this one merged as described here? |
What do you want to happen?
Kubebuilder is generating
main.go
scripts that are getting closed immediately when theManager
is done.Given that, we can add
LeaderElectionReleaseOnCancel: true
to the manager (with an explanation comment) to improve the performance of re-election.Extra Labels
No response
The text was updated successfully, but these errors were encountered: