Skip to content
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

Plugins Ecosystem Next - Meta issue #2016

Closed
3 of 4 tasks
camilamacedo86 opened this issue Feb 13, 2021 · 5 comments
Closed
3 of 4 tasks

Plugins Ecosystem Next - Meta issue #2016

camilamacedo86 opened this issue Feb 13, 2021 · 5 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Milestone

Comments

@camilamacedo86
Copy link
Member

camilamacedo86 commented Feb 13, 2021

The propose of this issue is we try to centralize all discussed implementations over the plugin ecosystem for we have a summary definition of all goals and steps that we would like to persuade as their motivations. In this way, we can easily have a better idea and not allow one solution to invalidate another. The details can be found in each task/issue.

It will allow us to define more than 1 plugin in the default layout of a project. The layout defines the default/layout plugin(s) config for the project. By doing that, any action/command executed for this configuration would call and use all plugins defined as the default for the project.

Allow a user to decide what execution should or not receive the additional plugins scaffolds. By using the declarative.kubebuilder.io/v1 from above in this scenario users would able to decide what API should or not use the addon pattern instead of applying it for the full project which is the current behaviour before #1991 get merged.

Allow the community to create any language/type plugin using the same base/config defined by KB in order to ensure its compatibility and/or maintainability.

PS.: Shows that after the above implementations this latest task would be responsible to only check the possibility of the plugins be as separate binaries that can be discovered by the Kubebuilder CLI binary via user-specified plugin file paths

@Adirio
Copy link
Contributor

Adirio commented Feb 17, 2021

#2019 relates to the second point

@camilamacedo86 camilamacedo86 added this to the next milestone Feb 23, 2021
@camilamacedo86 camilamacedo86 added the triage/accepted Indicates an issue or PR is ready to be actively worked on. label Feb 23, 2021
@daniel-garcia
Copy link

Unrelated question: are there any examples of writing a plugin? I can't seem to find anything in the kubebuilder book... maybe I'm not looking in the right place.

@Adirio
Copy link
Contributor

Adirio commented Mar 17, 2021

Unrelated question: are there any examples of writing a plugin? I can't seem to find anything in the kubebuilder book... maybe I'm not looking in the right place.

Not really, but planned. This PRs haven't been merged yet so its a bit early. #2060 implements it so you can use the pkg/plugins folder as examples.

@camilamacedo86
Copy link
Member Author

camilamacedo86 commented Mar 17, 2021

Hi @daniel-garcia,

It is not planned here. However, after we get merged #2015 you can for example run kb it --plugins=config/v1 and get the common base and then, you can indeed scaffold the files with the language that you wish.

I created the task to track it: #2098
however, it is my todo list already :-)

@camilamacedo86
Copy link
Member Author

I am closing this one since now we have only #1378 to be addressed. Then, has no longer need for a meta issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

No branches or pull requests

3 participants