kubebuilder
kubebuilder copied to clipboard
Distinct between Plugins and Bundle Plugins
What do you want to happen?
Following up on today's meeting-
Currently, we have two terms that are very confusing:
- "Plugins" - a (decoupled) component that is used to scaffold language code (such as Kustomize YAMLs, Go code, Java code, etc.)
- "Bundle Plugins" - a composition of a few plugins. The bundles allow a friendly user interface for end-users around common use cases, I.E: "go bundle" combines Kustomize+go/v3
Following up on the call, we should separate these two terms into Plugins and Bundles and reflect the documentation/code accordingly.
Extra Labels
/kind documentation, /kind cleanup
@AlmogBaku: The label(s) kind/documentation,, kind//kind
cannot be applied, because the repository doesn't have them.
In response to this:
What do you want to happen?
Following up on today's meeting-
Currently, we have two terms that are very confusing:
- "Plugins" - a (decoupled) component that is used to scaffold language code (such as Kustomize YAMLs, Go code, Java code, etc.)
- "Bundle Plugins" - a composition of a few plugins. The bundles allow a friendly user interface for end-users around common use cases, I.E: "go bundle" combines Kustomize+go/v3
Following up on the call, we should separate these two terms into Plugins and Bundles and reflect the documentation/code accordingly.
Extra Labels
/kind documentation, /kind cleanup
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
I would like to do some clarifications which I think I could not do properly in the meeting.
A bundle is a mechanism that allows us to create a plugin by composition. It is part of the Kubebuilder API and only matters for kubebuilder maintainers or for those who are looking to extend Kubebuilder and use it as a lib. See: https://github.com/kubernetes-sigs/kubebuilder/blob/master/pkg/plugin/bundle.go
PS.: For further information, please check the plugins docs: https://book.kubebuilder.io/plugins/plugins.html as its design docs.
Because of this, I can not go along with the definition added in the description of this issue.
For this specific case, still not clear what are the proposed changes. Would you like to change the docs or the api names? Sorry, but I am unable to follow the idea of Distancing between Plugins and Bundle Plugins
. The plugin is the concept when the bundle is an API that allows us to create a plugin by composition.
What do you think about trying to propose a PR with the changes that you think should be done? It might help us understand better what changes you see that should be addressed and where. Also, all help is more than welcome. WDYT?
c/c @rashmigottipati @ryanbrainard @jmrodri @varshaprasad96
Hi @AlmogBaku,
Could you please clarify what should be done here or let us know if the above explanation sorted out your concerns and we can close this one?
I disagree. The fact that we have written in the API or the documentation doesn't mean we can't change it.
Although technically-wise plugins can be built of a bundle of plugins, this is very confusing from a product point of view.
My suggestion is to rename the bundle plugins concept to be just "bundles". The fact that bundles are implemented behind the scenes as a plugin, doesn't contradict it.
@AlmogBaku,
My suggestion is to rename the bundle plugins concept to be just "plugins".
A Bundle cannot be called Plugin because we cannot have two diff APIs with the same name.
A bundle is == composition with 1..Many plugins to build a plugin Plugin is == a plugin
The fact that bundles are implemented behind the scenes as a plugin, doesn't contradict it.
A Bundle is an API that allows us to build a Plugin via composition. A Bundle of Plugins. So, I am afraid that I cannot follow up on this one.
So, could you please clarify what exactly should change? What exactly is confusing for you? Do you want to change a doc? Do you want to change the API? It is still not clear to me what is the suggestion here. WDYT about you push a pull request with what do you want to change? it might help us understand your thoughts and suggestions. However, if you want to change the API then we probably need a design doc for that.
Sorry, I meant:
My suggestion is to rename the bundle plugins concept to be just "bundles".
HI @AlmogBaku,
My suggestion is to rename the bundle plugins concept to be just "bundles".
Where the change should be made?
Also, see that only "bundles" does not specify bundles of what
The SDK (consumer of KB) has "OLM Operator Bundles" which are used to integrate the projects with OLM.
I suggest changing the names only in the docs and comments. The problem is mostly when communicating, it's not a techy issue.
Hi @AlmogBaku,
The only place that we have it is in : https://github.com/kubernetes-sigs/kubebuilder/blob/6a2384761944cf5e096df0255e213c8bec111aaf/docs/book/src/plugins/creating-plugins.md#L15
So, if you want to create a PR for replacing Bundle Plugin for Bundle only in this doc it seems fine for me since in the doc we have a context to describe what that means.
It was discussed in the KB meeting today and we agree to try to improve the [doc][https://github.com/kubernetes-sigs/kubebuilder/blob/6a2384761944cf5e096df0255e213c8bec111aaf/docs/book/src/plugins/creating-plugins.md#L15] to bring a better clarification.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/stale
is applied - After 30d of inactivity since
lifecycle/stale
was applied,lifecycle/rotten
is applied - After 30d of inactivity since
lifecycle/rotten
was applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale
- Mark this issue or PR as rotten with
/lifecycle rotten
- Close this issue or PR with
/close
- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/stale
is applied - After 30d of inactivity since
lifecycle/stale
was applied,lifecycle/rotten
is applied - After 30d of inactivity since
lifecycle/rotten
was applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle rotten
- Close this issue or PR with
/close
- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/stale
is applied - After 30d of inactivity since
lifecycle/stale
was applied,lifecycle/rotten
is applied - After 30d of inactivity since
lifecycle/rotten
was applied, the issue is closed
You can:
- Reopen this issue with
/reopen
- Mark this issue as fresh with
/remove-lifecycle rotten
- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
In response to this:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/stale
is applied- After 30d of inactivity since
lifecycle/stale
was applied,lifecycle/rotten
is applied- After 30d of inactivity since
lifecycle/rotten
was applied, the issue is closedYou can:
- Reopen this issue with
/reopen
- Mark this issue as fresh with
/remove-lifecycle rotten
- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.