CRD apiGroup option - Githubissues

kubernetes-sigs / kubebuilder

Kubebuilder - SDK for building Kubernetes APIs using CRDs

http://book.kubebuilder.io

Apache License 2.0

7.91k stars 1.45k forks source link

CRD apiGroup option #604

Closed lluunn closed 5 years ago

lluunn commented 5 years ago

We want to create a CRD with spec:

apiVersion: kubeflow.org/v1alpha1
kind: Notebook

However, IIUC we can't achieve this with kubebuilder now because

kubebuilder defines an "Org" in PROJECT file, default to k8s.io
when creating api, we specify a Group
and then apiGroup will be Org.Group

The group name will be the dir name under pkg/apis, so we chose "notebook". Our org is "kubeflow.org". So the generated CRD is:

apiVersion: notebook.kubeflow.org/v1alpha1
kind: Notebook

Is there any way to generate the CRD so that apiGroup is "kubeflow.org"?

Thanks!

Adirio commented 5 years ago

TLDR: no

You should not use "notebook" as your group name. It is the resource kind not the group name. You should find a group name that you feel confortable with and use that (e.g. "machinelearning").

/triage support

lluunn commented 5 years ago

I know notebook should not be the group name.

But the problem is, we want the apiGroup to be "kubeflow.org", and there is no way to achieve that.

Adirio commented 5 years ago

As said, the short answer is: no, it can not be done.

Some nice group names you may consider are:

api.kubeflow.org: this is my favorite.
resources.kubeflow.org: similar to the previous, but I like better the former.
machine-learning.kubeflow.org: according to your webpage that is what you do. Any variations replacing the - by a . or just removing it could also be nice.

jnodorp commented 5 years ago

Leaving a warning here: api will not work as a group name. It seems to confuse the CRD generation (it replaces api with the version leaving you with something like alphav1.example.com as a group name).

DirectXMan12 commented 5 years ago

@jschlichtholz that sounds like a bug that we need to fix.

P.S. This should now be doable with controller-tools -- it'll take a bit of manual editing, but it should work fine.

fejta-bot commented 5 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

fejta-bot commented 5 years ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten

fejta-bot commented 5 years ago

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close

k8s-ci-robot commented 5 years ago

@fejta-bot: Closing this issue.

In response to [this](https://github.com/kubernetes-sigs/kubebuilder/issues/604#issuecomment-546658569): >Rotten issues close after 30d of inactivity. >Reopen the issue with `/reopen`. >Mark the issue as fresh with `/remove-lifecycle rotten`. > >Send feedback to sig-testing, kubernetes/test-infra and/or [fejta](https://github.com/fejta). >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.