forked from kubernetes-sigs/kubebuilder
-
Notifications
You must be signed in to change notification settings - Fork 5
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
It introduces a roadmap for 2025 with our main goals for the year
- Loading branch information
1 parent
40db2b8
commit 7546c96
Showing
1 changed file
with
39 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,39 @@ | ||
# Kubebuilder Project Roadmap 2025 | ||
|
||
### Ensure Webhook Implementation Stability and Enhance User Experience | ||
|
||
The current Webhook implementation has some stability issues and areas where user experience could be improved. To achieve a stable and user-friendly Webhook implementation, we aim to address the following: | ||
|
||
- **CA Injection**: Ensure that CA injection for conversion webhooks is limited to the relevant Custom Resource (CR) conversions. | ||
- **Scaffolding Multiple Webhooks**: Enable the scaffolding of multiple webhooks for the same API version. | ||
- **Hub and Spoke Model**: Integrate a hub-and-spoke model for conversion webhooks to streamline implementation. | ||
- **Comprehensive E2E Testing**: Expand end-to-end (E2E) tests for conversion webhooks to validate not only CA injection but also the conversion process itself. | ||
- **E2E Test Scaffolding**: Improve the E2E test scaffolds under `test/e2e` to validate conversion behavior beyond CA injection for conversion webhooks. | ||
- **Enhanced Multiversion Tutorial**: Add E2E tests specifically for conversion webhooks in the multiversion tutorial to support comprehensive user guidance. | ||
|
||
### Align Tutorials Samples with Best Practices and layout proposed by the DeployImage Plugin | ||
|
||
The existing tutorials do not consistently follow best practices or | ||
the layout proposed by the DeployImage plugin. Ensuring alignment with | ||
these standards will improve tutorial quality and usability by: | ||
|
||
- **Controller Logic Consistency**: Standardize tutorial controller logic to match the DeployImage plugin’s scaffolded controller, including practices around conditions, finalizers, and status updates. | ||
- **Conditional Status in CronJob Spec**: Incorporate conditional status handling in the CronJob spec to align with best practices. | ||
- **Test Logic Consistency**: Ensure tutorial test logic mirrors the tests scaffolded by the DeployImage plugin, adapting as needed for specific cases. | ||
|
||
### Provide Solution to Keep Users Updated with the Latest Changes | ||
|
||
Currently, Kubebuilder offers the *Help to Upgrade* feature, allowing users to | ||
re-scaffold their project using the `kubebuilder alpha generate` command. | ||
However, this approach still requires significant manual effort to apply | ||
updates across projects. | ||
|
||
The goal is to explore opt-in mechanisms that notify users and automate | ||
updates in their repository, keeping them aligned with the latest | ||
Kubebuilder version. This would facilitate staying up-to-date and reduce | ||
the maintenance burden on users. Inspired by Dependabot, we aim to create | ||
a solution that helps maintain compatibility with new Kubebuilder features, | ||
best practices, and bug fixes with minimal manual intervention. | ||
|
||
A work-in-progress proposal is currently under development: [WIP Proposal #4302](https://github.com/kubernetes-sigs/kubebuilder/pull/4302/files). | ||
|