Kubebuilder: `kubebuilder create resource --group concourse-ci.org` fails

[jchesterpivotal]

When I use concourse-ci.org as my --group param, I see:

2018/07/02 12:06:21 --group must match regex ^[a-z]+$ but was (concourse-ci.org)

I would expect this to succeed. The problem appears to be that the validating regex does not cover all legal domain names, which may contain numbers and hyphens.

---

$ kubebuilder version
Version: version.Version{KubeBuilderVersion:"0.1.12", KubernetesVendor:"1.10", GitCommit:"a523fb6b174c2785084eb0948c4cfdaf2f818bc4", BuildDate:"2018-06-21T20:07:48Z", GoOs:"unknown", GoArch:"unknown"}

[jchesterpivotal]

Actually, it seems to reject all domains, because . is also not in the regex ^[a-z]$.

[fanzhangio]

Hi @jchesterpivotal , the group name passed after --group should follow regex pattern ^[a-z]+$ which only contains lower-case character combinations. It should be not empty, capital, or other symbols. So - and . are not allowed.

Thanks

[jchesterpivotal]

Yes, I found that regex when I was investigating.

My report might better be phrased as "group regex incorrectly rejects permissible domain names".

[sttts]

Why this restriction of ^[a-z]+$? Apimachinery and the code generators support multi-segment domains and - as well.

[daviddyball]

Just wanted to chime in and say that this also prevents the usage of digits in the group name which seems unusual. Presumably the idea is to keep the group+domain within the DNS naming convention, but that should still allow for digits in the group or domain name.

[ZYecho]

I think the correct way is using kubebuilder init --domain to assign your domain name. not only rely on kubuilder create --group

[jchesterpivotal]

I don't at this point recall if --domain was available at the time.

[madhusudancs]

We want to create multiple API groups in a project and not all of them have the same domain suffix as the project domain name passed through kubebuilder init --domain flag. It will be really useful if this can be fixed.

[mengqiy]

I see 2 ways to fix it:

• we don't use domain anymore, the user must always provide a FQN as group name.
• we still keep using domain, if the user provide a FQN as group name, we use it as is; otherwise, we use groupname+domain.

[DirectXMan12]

Why this restriction of ^[a-z]+$

To clarify, as noted above, the original intention was that you'd specify those parts in domain, and then group would be the prefix to domain, as well as the package name for your group. This meant that you didn't need to re-specify domain every time you ran the command, and it was fairly easy to choose a package name.

That, at least, was the original intention. I'm not against changing that, but I'd like to preserve at least some warning if you're not choosing a foo.bar.tld-style group name (or more), since that's generally what we recommend.

[jchesterpivotal]

I'm a bit confused by this argument. If you want folks to choose domain names, then it ought to be from the set of permissible domain names. I didn't pluck concourse-ci.org out of a hat: it's a valid, registered domain. Why should foo-bar.tld be rejected?

[DirectXMan12]

right, the current way is to do

kubebuilder init --domain concourse-ci.org
kubebuilder create resource --group something

This creates a full group name of something.concourse-ci.org, with the group's package being pkg/apis/something/<version>. The only reason we don't accept concourse-ci.org as a group name right now is that it's not a valid go package name. It'd be fine as the base domain, as above.

We generally recommend 3+-part names since it makes it easier to split things up later or add new groups (e.g. authentication.k8s.io vs apiregistration.k8s.io), which is why the tool is currently set up that way.

Since, with the new scaffolding layout, we don't need the group "prefix" to be a package name, so we could hypothetically get rid of the distinction between "domain" and "group [prefix]"

[jchesterpivotal]

Thanks for the explanation. Perhaps this could be surfaced some other way?

Or some canonicalisation could be applied to enable golang to emulate the advanced package-naming capabilities of Java 1.0?

[DirectXMan12]

We could hypothetically try. We have a // +groupName marker that makes it possible to manually specify group name. It's not super high on our priority list right now, since KB itself tries to encourage good patterns for naming according to how we do things in kubernetes.

I'm going to close this for now for book keeping purposes, but I'd be happy to review a PR to update the scaffolding to support your usecase a bit better, because it does come up on occasion.