🐛 fix support for external types by allowing the domain be empty, and properly generate the sample for cert-manager.

[camilamacedo86]

• Allowing the domain be empty since some scenarios this value might not be required
• Use io as the domain to fix the scaffold sample for cert-manager and update the example in the documentation.

[camilamacedo86]

Hi @fischor

Could you please validate it?
I think we need to use the domain to generate the RBAC in this case
Then, do we really need the domain?

[camilamacedo86]

Hi @fischor,

Thank you so much! That’s exactly the help I was looking for. We discussed the scenarios to ensure that it will work well.

Your comment made me think: actually, CertManager does not define domains for their APIs, just the group. So, we must accommodate both scenarios—allowing the API to be scaffolded with only the group or with both the group and the domain. 

In this way, see that we are fixing here how we scaffold and allowing the scaffold be done with an empty domain.

[fischor]

Seems to work like this. But its a bit counter-intuitive. For me "cert-manager.io" feels like a domain without a group.

But of course, we need a group since that is used e.g. as folder name. Can you explain why is the group mandatory? Where is it used except as folder name?

[camilamacedo86]

My point here is more about how we recommend using the feature and if we should or not make the domain mandatory at this point. We could suggest that "io" is treated as the domain and "cert-manager" as the group to provide a complete scaffold structure. At the same time, we can allow the group to remain empty for those who prefer to tweak the configuration manually. There's no need to block this flexibility at the moment but it might generate invalid scaffolds.

Note that APIGroup technically can ONLY be empty when scaffolding core types and not external types.

Kubebuilder utilizes the API group in several places, including code generation, and RBAC markers, all of which are critical for scaffolding Kubernetes controllers. If the group is left empty, the scaffolding process generated might be incomplete or invalid. Also, we provides two project layouts:

• Single group: where all APIs belong to one group.
• Multigroup: where multiple groups are supported under one project.

Without proper directory structure, scaffolding might becomes problematic, as resources won't be correctly organized accordingly.

Why would we recommend keeping the group empty instead of the domain?

[camilamacedo86]

Hi @fischor,

In my opinion, groups should not be empty when dealing with non-core types in scaffolds. The concepts should stay aligned with Kubernetes itself. We cannot have Kubebuilder diverging from core Kubernetes principles. However, in order to not block others scenarios we should not make mandatory users provide the Domain.

What are your thoughts?

[fischor]

I am refering to the "group" (--group) as used in kubebuilder, not the Kubernetes apiGroup.
The apiGroup will not be empty if you do --domain cert-manager.io --group "", it will be cert-manager.io then.

My thoughts are that is does not make sense to have --domain and --group for external APIs, since these are kubebuilder specific entities and not all external APIs use that scheme. Maybe just --api-group is better to specify the (full) apiGroup for external APIs.

[varshaprasad96]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: camilamacedo86, varshaprasad96

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 [camilamacedo86,varshaprasad96]

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