Invalid leader election ID is generated

[yaa110]

Invalid leader election ID is generated

[camilamacedo86]

Hi @yaa110,

See that the value is generated here: https://github.com/kubernetes-sigs/kubebuilder/blob/master/pkg/plugins/golang/v4/scaffolds/internal/templates/main.go#L282

LeaderElectionID: "{{ hashFNV .Repo }}.{{ .Domain }}",

So, can you please share with us what values do you use to to create the project?
How we can reproduce it so that it can help us to fix it?

[camilamacedo86]

This one seems to be a good first issue.
What we need to do here:

• a) First, we must see if we can reproduce the described issue. To do so, create a new project and ensure that the LeaderElection is enabled in the cmd/main.go. ( See: https://github.com/kubernetes-sigs/kubebuilder/blob/master/testdata/project-v4/cmd/main.go#L62C2-L64C77 ) If not, then we can close this one
• b) IF we are able to reproduce then, we need to change the implementation https://github.com/kubernetes-sigs/kubebuilder/blob/master/pkg/plugins/golang/v4/scaffolds/internal/templates/main.go#L282 to ensure that we are generating a random valid value. Also, we should ensure that this scenario is validated in the e2e tests. So, we need to change the test for go/v4 to deploy the project with leaderElection enabled, see: https://github.com/kubernetes-sigs/kubebuilder/tree/master/test/e2e/v4

[Bharadwajshivam28]

Hey @camilamacedo86 I can take a look on this issue

[Bharadwajshivam28]

I need some steps to get started as I am new contributor

[yaa110]

Thank you @camilamacedo86. According to the source code you shared, the issue is connected to the empty domain value I set for the init command:

kubebuilder init --domain "" --repo github.com/blah/blah --project-name mykind
kubebuilder create api --group domain.com --version v1 --kind MyKind

It would be nice to also take this situation into consideration.

[camilamacedo86]

@yaa110

Great job !!! thank you for check this one

kubebuilder init --domain "" --repo github.com/blah/blah --project-name mykind

So, the root cause is to empty the domain.
Why should we allow that? Why did you create the project with an empty domain?
Therefore, just adding a validation to ensure it fails should be enough.
I do not know if other options will properly work with an empty domain.

@yaa110

Would you like to push a PR so we add validation and do not allow this scenario?
WDYT?

[yaa110]

@camilamacedo86 I intended to use an API group of domain.com. Therefore, if I had set the domain, I would have expected to create the following resource sample, which was deemed unacceptable (observe the value of the apiVersion field):

using:

kubebuilder init --domain "domain.com" --repo github.com/blah/blah --project-name mykind
kubebuilder create api --group domain.com --version v1 --kind MyKind

generates:

apiVersion: domain.com.domain.com/v1
kind: MyKind
spec: {}

however, using aforementioned commands (with empty domain), generates:

apiVersion: domain.com/v1
kind: MyKind
spec: {}

Is it a bad idea to leave the domain blank? Does it cause issues beyond the leader election ID? Wouldn't it be better to allow the domain to be empty and change the templating code accordingly to support it?

{{ if .Domain }}
LeaderElectionID:       "{{ hashFNV .Repo }}.{{ .Domain }}",
{{ else }}
LeaderElectionID:       "{{ hashFNV .Repo }}",
{{ end }}

[uos-ljtian]

Maybe I can check and see if I need to submit a PR

[camilamacedo86]

Hi @yaa110,

The "domain" and "group" serve different purposes in structuring and naming resources. A "domain" usually refers to the base DNS domain name used for all resources, serving as a namespace to group them under a common name, preventing conflicts across different projects or organizations.

A "group", on the other hand, is a subdivision within the domain that categorizes related kinds of resources, allowing for clearer organization and resource management within the domain.

Example if your base domain is example.com, you might define a resource in the ships group. The full API Group for a resource named Sloop would be ships.example.com.

So, the domain should be filled with the domain of your project.

Using empty domains in Kubernetes could bring issues like:

• Naming Conflicts: Easier creation of resources that might conflict with others, potentially causing overwrites or interference.
• Identification Problems: Complications in identifying or categorizing resources, affecting management and deployments.
• Integration Challenges: Potential difficulties in integrating with tools or systems that expect domain-based naming conventions.

Therefore, I thought in not allow empty domains. However, others might either done the same.
In this way, the second option approach might be as you suggested use only the repo instead of the repo + domain seems OK too

I am OK within as well if you want to push this change.`

replace: "{{ hashFNV .Repo }}.{{ .Domain }}",

with: LeaderElectionID: "{{ hashFNV .Repo }}", (ONLY when the domain is not informed)