🐛 Add leader election namespace to fix manager start error

[astraw99]

Fixes #3016
On generated code main.go L57, just set leader-election to true:

flag.BoolVar(&enableLeaderElection, "leader-elect", true, ...

Then make run will got error:

go run ./main.go
1.665666448465308e+09   ERROR   setup   unable to start manager {"error": "unable to find leader election namespace: not running in-cluster, please specify LeaderElectionNamespace"}
main.main

This PR is to add leader election namespace to fix this issue.
Plugins go/v3 and go/v4-alpha are updated.

[k8s-ci-robot]

Hi @astraw99. 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 /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

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.

[camilamacedo86]

What about we add an e2e test with the leader election enabled for go/v3 and go/v4 scaffolded projects in: https://github.com/kubernetes-sigs/kubebuilder/tree/master/test/e2e?

In this case, I think we would need to create a NEW test which will update the config/manager to pass the arg with the value == true.

[astraw99]

Checked code in https://github.com/kubernetes-sigs/kubebuilder/blob/master/pkg/plugins/common/kustomize/v2-alpha/scaffolds/internal/templates/config/manager/config.go#L118-L121

The e2e test in https://github.com/kubernetes-sigs/kubebuilder/blob/master/test/e2e/v3/generate_test.go#L38 and https://github.com/kubernetes-sigs/kubebuilder/blob/master/test/e2e/v4/generate_test.go#L38, the --component-config flag is not set, then will generate config/manager with --leader-elect set true.

So maybe it is enough to test the leader election enabled.
PTAL thanks.

[camilamacedo86]

See that we have a test with the componentConfig enabled, see:

kubebuilder/test/e2e/v4/plugin_cluster_test.go

Lines 91 to 96 in cf154d6

	It("should generate a runnable project"+
	" with restricted pods and with --component-config field enabled", func() {
	kbc.IsRestricted = true
	GenerateV4ComponentConfig(kbc)
	Run(kbc)
	})

Then, we could add +1 test to mock the same but update the config/manager.yaml to ensure that the leader election is also enabled and test it with the namespace.

My concern here is that the namespace has not been added and we do not face any issues when we are using deploy IMG command to check it against a cluster. The error is only faced using make run to test it outside of the cluster. So that we need to ensure that the change will not break the prod/current behaviour. So we might want to address the need via doc and not in the default scaffold.

[astraw99]

Yes, agree with the concerning here.
Tested again both in and outside of the cluster, the LeaderElectionNamespace is unnecessary to set here when deploy in cluster.

So add it in the comment doc to resolve the issue: if set "leader-elect = true" then "make run" to test the project outside of the cluster.
PTAL thanks.

[camilamacedo86]

Hi @astraw99,

That is great. We have the desire for too long and many issues tracked for we add in a FAQ section.
So, wdyt about create a PR to add a FAQ section in the KB docs that would be like https://sdk.operatorframework.io/docs/faqs/ to address this one?

See all issues to track in this FAQ section that we need to add to the docs: https://github.com/kubernetes-sigs/kubebuilder/issues?q=is%3Aissue+is%3Aopen+FAq

[astraw99]

OK, I will create a FAQ section in the KB docs, and include some of the representational reported issues.
And update it continuously, to help more users :)

[astraw99]

@camilamacedo86 Opened a FAQ PR #3044
PTAL thanks.

[camilamacedo86]

/ok-to-test

[camilamacedo86]

/hold

These changes have broken the projects and are not passing in the e2e tests.

 <*errors.errorString | 0xc000186030>: {
          s: "kubebuilder init --plugins go/v3 --project-version 3 --domain example.comjxud failed with error: (exit status 1) Writing kustomize manifests for you to edit...\nWriting scaffold for you to edit...\nError: failed to initialize project: unable to scaffold with \"base.go.kubebuilder.io/v3\": template: *templates.Main:65:31: executing \"*templates.Main\" at <.ProjectName>: can't evaluate field ProjectName in type *templates.Main\nUsage:\n  kubebuilder init [flags]\n\nExamples:\n  # Initialize a new project with your domain and name in copyright\n  kubebuilder init --plugins go/v3 --domain example.org --owner \"Your name\"\n\n  # Initialize a new project defining a specific project version\n  kubebuilder init --plugins go/v3 --project-version 3\n\n\nFlags:\n      --component-config         create a versioned ComponentConfig file, may be 'true' or 'false'\n      --domain string            domain for groups (default \"my.domain\")\n      --fetch-deps               ensure dependencies are downloaded (default true)\n  -h, --help                     help for init\n      --license string           license to use to boilerplate, may be one of 'apache2', 'none' (default \"apache2\")\n      --owner string             owner to add to the copyright\n      --project-name string      name of this project\n      --project-version string   project version (default \"3\")\n      --repo string              name to use for go module (e.g., github.com/user/repo), defaults to the go package of the current working directory.\n      --skip-go-version-check    if specified, skip checking the Go version\n\nGlobal Flags:\n      --plugins strings   plugin keys to be used for this subcommand execution\n\n2022/10/17 16:00:25 failed to initialize project: unable to scaffold with \"base.go.kubebuilder.io/v3\": template: *templates.Main:65:31: executing \"*templates.Main\" at <.ProjectName>: can't evaluate field ProjectName in type *templates.Main\n",
      }
      kubebuilder init --plugins go/v3 --project-version 3 --domain example.comjxud failed with error: (exit status 1) Writing kustomize manifests for you to edit...
      **Writing scaffold for you to edit...
      Error: failed to initialize project: unable to scaffold with "base.go.kubebuilder.io/v3": template: *templates.Main:65:31: executing "*templates.Main" at <.ProjectName>: can't evaluate field ProjectName in type *templates.Main**

See that for you are able to have the project name <.ProjectName> the boilerplate that defines the main.go must use machinery.ProjectNameMixin. You can look for code examples in the project implementation.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: astraw99
Once this PR has been reviewed and has the lgtm label, please assign camilamacedo86 for approval by writing /assign @camilamacedo86 in a comment. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

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

[astraw99]

/hold

These changes have broken the projects and are not passing in the e2e tests.

 <*errors.errorString | 0xc000186030>: {
          s: "kubebuilder init --plugins go/v3 --project-version 3 --domain example.comjxud failed with error: (exit status 1) Writing kustomize manifests for you to edit...\nWriting scaffold for you to edit...\nError: failed to initialize project: unable to scaffold with \"base.go.kubebuilder.io/v3\": template: *templates.Main:65:31: executing \"*templates.Main\" at <.ProjectName>: can't evaluate field ProjectName in type *templates.Main\nUsage:\n  kubebuilder init [flags]\n\nExamples:\n  # Initialize a new project with your domain and name in copyright\n  kubebuilder init --plugins go/v3 --domain example.org --owner \"Your name\"\n\n  # Initialize a new project defining a specific project version\n  kubebuilder init --plugins go/v3 --project-version 3\n\n\nFlags:\n      --component-config         create a versioned ComponentConfig file, may be 'true' or 'false'\n      --domain string            domain for groups (default \"my.domain\")\n      --fetch-deps               ensure dependencies are downloaded (default true)\n  -h, --help                     help for init\n      --license string           license to use to boilerplate, may be one of 'apache2', 'none' (default \"apache2\")\n      --owner string             owner to add to the copyright\n      --project-name string      name of this project\n      --project-version string   project version (default \"3\")\n      --repo string              name to use for go module (e.g., github.com/user/repo), defaults to the go package of the current working directory.\n      --skip-go-version-check    if specified, skip checking the Go version\n\nGlobal Flags:\n      --plugins strings   plugin keys to be used for this subcommand execution\n\n2022/10/17 16:00:25 failed to initialize project: unable to scaffold with \"base.go.kubebuilder.io/v3\": template: *templates.Main:65:31: executing \"*templates.Main\" at <.ProjectName>: can't evaluate field ProjectName in type *templates.Main\n",
      }
      kubebuilder init --plugins go/v3 --project-version 3 --domain example.comjxud failed with error: (exit status 1) Writing kustomize manifests for you to edit...
      **Writing scaffold for you to edit...
      Error: failed to initialize project: unable to scaffold with "base.go.kubebuilder.io/v3": template: *templates.Main:65:31: executing "*templates.Main" at <.ProjectName>: can't evaluate field ProjectName in type *templates.Main**

See that for you are able to have the project name <.ProjectName> the boilerplate that defines the main.go must use machinery.ProjectNameMixin. You can look for code examples in the project implementation.

Done, PTAL thanks.

[camilamacedo86]

Suggested change

	// If you set "leader-elect = true" then "make run" to test the project outside of
	// the cluster, should uncomment the following to set the leader-election namespace.
	// LeaderElectionNamespace: "your-ns",
	// You can enable the leader election. If you are testing the project locally using the "make run"
	// target which will run the manager outside of the cluster then, you might also need to set the
	// namespace the leader election resource will be created. You can uncomment the following
	// line. IMPORTANT: If you are running the project on the cluster with `make deploy` target
	// then, you might not want to add this option. So, you might want to customize this behaviour using
	// environment variables to only add this option for development purposes.
	// LeaderElectionNamespace: "<project-name>-system",

WDYT?

[camilamacedo86]

@astraw99

[camilamacedo86]

Hi @astraw99,

Thank you for the contribution 🥇

What do you think about the following suggestion:

		// You can enable the leader election. If you are testing the project locally using the "make run" 
		// target which will run the manager outside of the cluster then, you might also need to set the 
		// namespace the leader election resource will be created. You can uncomment the following
		// line. IMPORTANT: If you are running the project on the cluster with `make deploy` target
		// then, you might not want to add this option. So, you might want to customize this behaviour using
		// environment variables to only add this option for development purposes. 
		// LeaderElectionNamespace: "<project-name>-system",

Also, is that a bug? I think it is more additional. Note that we use the PR title to generate the changelog so wdyt about we change the PR for something like:

✨ add comment into the main.go to clarify the need to add the leader election namespace when the project is tested locally.

By last, should we really add it on the scaffold or would it be a better fit in a FAQ section? See that via doc we can indeed show and provide an example about adding it with ENV VAR, My concern here is we start to add too much in the default scaffold for edge cases that will bring confusion.

So, I would vote for we only doc that and not add in the default scaffold. It does not seem like a very common use case, right? I mean the error is not faced make creating a project and then running make run. It ONLY occurs if you explicitly enable the leader election when you are running outside of the cluster.

Is that make sense? If so, the title should be another like

📖 add a new FAQ section to clarify the need to add the leader election namespace when the project is tested locally.

/hold

[astraw99]

OK, this case is a little customized case, maybe it is more proper to add it into the FAQ section (I am doing).

[camilamacedo86]

Hi @astraw99,

The FAQ PR #3044 is merged so I think we can close this one. however, please feel free to re-open if you think that we should still be addressing this change in the scaffolds.