Allow different directory structure (related: multigroup)

[jaypipes]

I'd like to use kubebuilder for the new AWS Service Operator project. However, I'd like the following:

• Put the manager code in cmd/aws-service-operator/main.go instead of a main.go in the root project directory (note: I'd like all command/binary code in a top-level cmd directory since that is a Golang best practice IIANM)
• Put the CRDs in apis/{GROUP}/{VERSION}/{KIND}_types.go file (similar to multigroup=true planned functionality) -- e.g. apis/s3/bucket_types.go
• Put the controller code in pkg/controllers/{GROUP}/{KIND}_controller.go (note: I'd like all package code in a top-level pkg directory since that is a Golang best practice IIANM)

I could imagine a kubebuilder create api --api-path-template "apis/{group}/{version}/{kind}" --controller-path-template "pkg/controllers/{group}/{kind}" ... CLI command having the flexibility to deal with both multi-group and single-group desired directory layouts.

/kind feature

[jaypipes]

For the request to put the manager main.go file in a cmd/{PROJECT}/main.go location, I note that the kubebuilder init CLI command actually infers that the main.go file will be put in a cmd/manager/main.go location:

kubebuilder/cmd/init_project.go

Line 53 in 19458ba

- a cmd/manager/main.go to run

but that isn't accurate AFAICT

[Adirio]

I started working towards this goal (for example with #1252) but the syntax I used was "%[VARIABLE NAME]" following package fmt "%[1]" format instead of "{VARIABLE NAME}" as you suggested.

[fejta-bot]

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]

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

[camilamacedo86]

HI @DirectXMan12 and @mengqiy,
WDYT about it? What they are requesting here is not how it was in the V1 layout?

c/c @joelanford @estroz @hasbro17

[estroz]

Relates to #932. Possible solution:

This seems like a decent candidate to use as a test for plugins phase 2 -- it's mostly a matter of preference, and should be something that's easily doable under our general design currently.

/lifecycle frozen

[camilamacedo86]

Hi @jaypipes,

The items:

Put the CRDs in apis/{GROUP}/{VERSION}/{KIND}_types.go file (similar to multigroup=true planned functionality) -- e.g. apis/s3/bucket_types.go
Put the controller code in pkg/controllers/{GROUP}/{KIND}_controller.go (note: I'd like all package code in a top-level pkg directory since that is a Golang best practice IIANM)

It was addressed by command tool. You can use kb edit multigroup=true and then it will allow your scaffold to be in this format. See: https://book.kubebuilder.io/migration/multi-group.html?highlight=multi#single-group-to-multi-group

Regards:

Put the manager code in cmd/aws-service-operator/main.go instead of a main.go in the root project directory (note: I'd like all command/binary code in a top-level cmd directory since that is a Golang best practice IIANM)

Then, it relates to #932 as well as said in the above comment by @estroz.

Hi @DirectXMan12,

This change was made from V1 to V2 with the purpose to make the things easier but also shows that the community is not really happy with. So, I think would be valid consider. WDYT? Has some specific reason for the main.go be moved to the root instead of following the common practice? See for example https://github.com/golang-standards/project-layout#cmd