Repo Organization

[nmiculinic]

This is my suggestion for the kubecarrier repository organization:

/ --> all necessary stuff (README, LICENSE,...)
    - test --> holding e2e test file
    - api --> holding all the API definitions
    - ci --> (( maybe if we don't extract the CI stuff in separate repo as we talked earlier ))
    - pkg --> generic packages
    - cmd/{tender, manager, anchor, operator}/main.go --> all the `main.go` for each kubecarrier binary
    - config --> config CRDs etc
    - controller/{tender, manager, operator} --> controller for each kubecarrier component
    - docs
    - Makefile --> main kubecarrier task runner

I suggest having single go module, with single all encompassing API definitions.

[thetechnick]

I would propose some small adjustments:

- cmd/{tender, manager, anchor, operator}/main.go
- docs -> documentation and press material (icons, etc)
- hack -> scripts
- config/<component> -> kustomize stuff generated by kubebuilder (CRDs/RBAC)
- pkg -> public packages
  - apis/<group>/<version> -> Kubernetes APIs
  - internal or <package>/internal -> internal code for public API package (see controller-runtime for examples)
  - internal/<component> -> internal code for components (controller, etc)
- test -> e2e tests
- test/internal -> e2e framework
- Makefile -> main kubecarrier task runner

With this new folder structure, we will not be able to run kubebuilder create api commands, or have manual cleanup (file moving, etc) after running the command to do.

Questions:

• Where do we put the component Dockerfiles? ci/<component>/Dockerfile or config/<component>/Dockerfile
• As CI/CD stuff will live in a kubecarrier-pipelines repo, do we even need a ci directory?

Just to mention it: https://github.com/golang-standards/project-layout (Not a big fan of everything there, but we can draw inspiration for documenting our folder structure from there)

FYI: @jiachengxu

[jiachengxu]

Where do we put the component Dockerfiles? ci//Dockerfile or config//Dockerfile

I would like to put them in config//Dockerfile

As CI/CD stuff will live in a kubecarrier-pipelines repo, do we even need a ci directory?

Maybe we could start from ci folder from start and then move it to a dedicated repo?

[nmiculinic]

golang-standards...it's nothing official despite it's official sounding name

Where do we put the component Dockerfiles? ci//Dockerfile or > config//Dockerfile As CI/CD stuff will live in a kubecarrier-pipelines repo, do we even need a ci directory?

Let's move everything in the kubecarrier-pipelines repo and not even have ci directory here. For the dockerfile..... /config/<component>/Dockerfile

[nmiculinic]

- cmd/{tender, manager, anchor, operator}/main.go
- docs -> documentation and press material (icons, etc)
- hack -> scripts
- config/<component> -> kustomize stuff generated by kubebuilder (CRDs/RBAC)
- pkg -> public packages
  - apis/<group>/<version> -> Kubernetes APIs
  - internal or <package>/internal -> internal code for public API package (see controller-runtime for examples)
  - internal/<component> -> internal code for components (controller, etc)
- test -> e2e tests
- test/internal -> e2e framework
- Makefile -> main kubecarrier task runner

I don't see why test need internal package? Though sure, let's keep it private by default. In prototyping the framework came out quite generic and reusable

For the pkg keep in mind the cmd need to import stuff from there. Ergo, due to internal rules I'd suggest:

- pkg -> public packages
  - apis/<group>/<version> -> Kubernetes APIs
  - <component>/internal -> internal code for public API package
  - <component>/...  --> rest of the public facing code, including the include all controllers for the `cmd/<component>` imports

[thetechnick]

Oh, I thought that internal packages are private to the module and not tied to the package structure.

In this case, should we maybe use a top-level internal directory for our internal code?

Which would change the structure to:

- cmd/{tender, manager, anchor, operator}/main.go
- docs -> documentation and press material (icons, etc)
- hack -> scripts
- config/<component> -> kustomize stuff generated by kubebuilder (CRDs/RBAC)
- pkg -> public packages
  - apis/<group>/<version> -> Kubernetes APIs
  - <package>/internal -> internal code for public API package (see controller-runtime for examples)
- internal/<component> -> internal code for components (controller, etc)
- test -> e2e tests
- test/internal -> e2e framework
- Makefile -> main kubecarrier task runner

[nmiculinic]

I don't see the benefit in the /internal/... right now? what's preventing them from being under /pkg/internal/ and having one less folder in the top level structure?

The pkg should have a single file exposing the New{Tender/Manager/...}Command. The main.go files are they super simple, just using the pkg exposed NewTenderCommand.

hashicorp & kubernetes use this approach a lot. With creating new command, we can test CLI tools for consistency in their input/output without requiring execve syscall, recompilation, etc.

[thetechnick]

Ok, let's do it this way.

[nmiculinic]

I'll open the PR documenting this in the repo structure if that's fine with you?

[thetechnick]

already implemented