-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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.
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
📖 Improve plugin phase 1.5 EP #2075
📖 Improve plugin phase 1.5 EP #2075
Conversation
This way, CLIs will be able to define bundles, which will be used in the user-facing API and | ||
the plugin resolution process, but later they will be treated as separate plugins offering | ||
the maintainability and separation of concerns advantages that smaller plugins have in | ||
comparison with bigger monolithic plugins. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
User Stories
-
As operator developer would like to generate a project with custom plugins that will be used by default so that, after generating a project with a custom plugin such as
kb init—plugins=go/v3,declarative
all APIs scaffolded withkb create api
subcommand all APIs scaffold will be customized with the optional plugindeclarative
. -
As an operator developer would like to use a custom plugin just for a specific subcommand so that, I can, for example, use the declarative pattern only for a specific API and not for all project (e.g
kb create api
subcommand all APIs scaffold will be customized with the optional plugindeclarative
). More info; Allow every command to overwrite project-configured plugins #1941 -
As a KB maintainer/contributor and/or consumer I would like to know the plugins used to configure a project as its specific configurations and data when required so that, I can tooling upgrade and modifications actions to help the users implement smarter plugins. More info; Allow every command to overwrite project-configured plugins #1941
-
As a KB maintainer/contributor and/or consumer I would like to define a plugin is composed of 2 or more plugins so that, I can create a plugin that will re-use the code of other plugins and has customizations on top to address my need such as
go/v3 + helm/v3 + plugin that does all required adjustments that make my hybrid operator works
and to be able to extract the default configuration from the language files and provide different options for configuration without increase the maintainability and bring facilities to ensure the backwards compatibilities of the plugin. Also, I can easily imply that for example that any go/v3 plugin scaffold by my CLI also will be customized with my specific requirements which is a current SDK requirement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes proposed here are implemented in the PRs #2060 and operator-framework/operator-sdk#4581 already.
IMO it is very important because It allows the KB api starts to provide the required flexibilities for its consumer's plugin as SDK to be easier maintained as it shows a pre-requirement to start to promote solutions where people would write their own plugins to be integrated/useful for the tools.
In this way, I believe that is the first step for we have a design that allows us to start to play with.
Also, added some suggestions/ideas for clarifications such as by adding use cases and goals or non-goals of this proposal. Feel free to check and address them as, please you.
Otherwise, I have no objections and it shows great for me. 🥇
672f592
to
f2acc2a
Compare
Signed-off-by: Adrian Orive <[email protected]>
f2acc2a
to
83230ae
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Adirio, camilamacedo86, estroz The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@DirectXMan12 has a review incoming. /hold |
Nevermind, I think #2060 was the subject of discussion, not this PR. /hold cancel |
While implementing plugin phase 1.5 and aligning operator-SDK, several additional concepts that were not designed at first have raised. This PR improved on the plugin phase 1.5 design document including those changes.
Plugin phase 1.5 will be useful to achieve several goals in kubebuilder. For example, plugin chaining allows to split monolithic plugins into smaller ones, and plugin bundles maintain backwards compatibility towards the user.
This updated design has been validated with operator-SDK: operator-framework/operator-sdk/pull/4581