Skip to content

🌱 Clarify that controller-runtime is not a kubebuilder subproject #3185

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 31, 2025
Merged

🌱 Clarify that controller-runtime is not a kubebuilder subproject #3185

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 0 additions & 3 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -68,9 +68,6 @@ See [FAQ.md](FAQ.md)

Learn how to engage with the Kubernetes community on the [community page](http://kubernetes.io/community/).

controller-runtime is a subproject of the [kubebuilder](https://github.com/kubernetes-sigs/kubebuilder) project
in sig apimachinery.
Copy link
Member

@camilamacedo86 camilamacedo86 Mar 31, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the way we maintain the projects — whether or not they share maintainers — doesn’t define whether they are sub-projects of Kubebuilder. We may have the same maintainers or not, and that’s totally fine. IMO: This isn’t about OWNER aliases, but rather about the purpose and scope of the tools and projects themselves.

However, changes in controller-runtime should still take into account their impact on Kubebuilder — a tool maintained under the Kubernetes SIGs that builds on top of controller-runtime, promotes its usage, provides documentation, and helps users understand how to use it effectively.

While controller-runtime and controller-tools can technically be used independently of Kubebuilder, it’s Kubebuilder that has been the primary driver of their adoption in practice.

So, I’d like to suggest we rephrase it to something like:

Kubebuilder is built on top of the controller-runtime and controller-tools libraries, providing a higher-level scaffolding tool to help developers create Kubernetes APIs more easily.

Copy link
Member Author

@alvaroaleman alvaroaleman Mar 31, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is already in the readme: https://github.com/kubernetes-sigs/controller-runtime/blame/d8b679322d5cc466d12301b8875c42040fd29e46/README.md#L6-L8

We will keep on considering kubebuilders needs, this is just to clarify that these are independent projects.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is already in the readme: https://github.com/kubernetes-sigs/controller-runtime/blame/d8b679322d5cc466d12301b8875c42040fd29e46/README.md#L6-L8

I see — that makes sense, and that’s great to hear! 🎉

I agree that controller-runtime and controller-tools can be used independently of Kubebuilder, so I’m totally fine with the clarification.

/lgtm
/approve

That said, Kubebuilder has also been actively documenting and promoting both libraries over the years. We'd really love to receive help, feedback, and suggestions from the maintainers of controller-runtime and controller-tools to improve Kubebuilder’s scaffolding, documentation, and overall user experience.

We truly want to work together to ensure the success of all the projects and provide the best experience for the community. 🙌


You can reach the maintainers of this project at:

- Slack channel: [#controller-runtime](https://kubernetes.slack.com/archives/C02MRBMN00Z)
Expand Down
Loading