How external plugins can work with PROJECT config

[camilamacedo86]

What do you want to happen?

From aimuz:

At present, there seem to be many shortcomings in external plug-ins. For example, I want to implement a Layout plug-in. I refer to the implementation of go in the code, and cannot be well ported to external plug-ins. For now, I found that it relies on InjectConfig, but external plug-ins cannot provide

Do you have any good suggestions?

Extra Labels

No response

[camilamacedo86]

Hi @aimuz,

Thank you for raising this question. The InjectConfig will inject the config, the PROJECT file scaffolded by default.
Ideally, the external plugin should also track all input as it is done by the plugins shipped by KubeBuilder in this file.
More info; https://book.kubebuilder.io/reference/project-config.html

If you are using Golang to develop the external plugin, you can use kubebuilder as a lib and use all the same methods/functions to work on the scaffolds. Therefore, I understand that your external plugin could be like the plugins implemented in the OperatorSDK, for example, https://github.com/operator-framework/operator-sdk/tree/master/internal/plugins where they use Kubebuilder as a lib.

See that they also have their functions to work out with the PROJECT config since they can add other layouts, etc., which is not implemented in Kubebuilder: https://github.com/operator-framework/operator-sdk/blob/master/internal/plugins/manifests/v2/init.go#L52-L71

Would it address your question and let you move forward? If not, please let us know more about what you are doing. What do you expect to see? What is the behaviour faced? So that we can help you out.

Pinging @rashmigottipati and @everettraven since they most worked with the API to allow external plugins.

[m-messiah]

I suspect the answer was related to @aimuz =)

[aimuz]

I am currently trying to implement a Layout plugin based on kubebuilder, which is the same Layout as my current project's Layout. This way I can switch my project to kubebuilder in an incremental way.

Why not use kubebuilder's built-in Layout? The difference between kubebuilder's built-in Layout and my project's existing Layout is so big that I think it would be very risky to switch directly. So I want to implement a custom Layout plugin.

The reason why I didn't use a library is that I wanted to use the official kubebuilder and then extend it with an external plugin.

The main reason is this description of kubernetes-sigs/kubebuilder-declarative-pattern#293

KB release need not be blocked on KB-declarative-pattern to upgrade dependencies during every K8s release cycle.
The maintenance and release of KB-declarative-plugin can be handled independently, instead of relying on KB.

My ideal situation is like this, if I need to add plugins.

kubebuilder ext add github.com/operator-framework/operator-sdk

kubebuilder ext add ....

or some other plugin that

The description may be messy, if you have any questions, please feel free to find me

[camilamacedo86]

Hi @m-messiah

The reason why I didn't use a library is that I wanted to use the official kubebuilder and then extend it with an external plugin.

Why do you mean with? If you use Kubebuilder as a LIB you will have the official kubebuilder scaffold and you can extend it.

My ideal situation is like this, if I need to add plugins.
kubebuilder ext add github.com/operator-framework/operator-sdk
kubebuilder ext add ....

If you want to use the SDK scaffold you cannot use it as a lib, They only provide the CLI and does not allow you import it.
However, you could have the SDK binary and have a code that will call its commands. Your own custom plugin could do that and just run the command line operator-sdk init ... beforehand. See in the code examples where we call make command, and etc. You can do the same.

Then, you could use SDK (which is an Kubebuilder extension) to run your external plugin after it generates the project. SDK should also provides the same option.

[aimuz]

Hi @camilamacedo86

Why do you mean with? If you use Kubebuilder as a LIB you will have the official kubebuilder scaffold and you can extend it.

Yes, if you can only introduce kubebuilder as a library, won't the official kubebuilder cli not work and you have to use a custom binary?

Then, you could use SDK (which is an Kubebuilder extension) to run your external plugin after it generates the project. SDK should also provides the same option.

No, I don't want to use operator-sdk, I just use operator-sdk as an example.

---

As an example

I brought in kubebuilder as a library as well as operator-sdk, added some of my custom plugins, and it worked fine at this point, so I'll call it custom-kube-sdk here. Later I got some features of operator-sdk such as the helm plugin.

Do I need to bring operator-sdk as a library into my custom-kube-sdk project to get this functionality?

So far it looks like it has to be

---

So let's take a different approach at this point. If the helm plugin in operator-sdk is provided through external plugins, and my project is also provided through external plugins, then they can be combined in a very simple way, no code changes, just a binary download.

If this needs to be supported, kubebuilder needs to make the external plugins interface no weaker than the way the library is introduced. This approach allows kubebuilder to have a much larger ecosystem, which means that I can implement plugins in any language and have plugins that aren't weaker than the way libraries are introduced.

Thank you

[m-messiah]

@camilamacedo86 please check the mentions and mention the author of the issue - @aimuz, rather than me

[everettraven]

@aimuz Before I provide any answers I want to make sure I am understanding the ask properly. I am going to try to summarize the ask, but please do correct me if I am wrong.

From what I understand, you are:

• Writing an external plugin
• Wanting to be able to read/modify the PROJECT file (or any other file) that has been created by previous plugins from the external plugin

[varshaprasad96]

One of the issue which needs to be added here is that the external plugins do not have access to Config as they do not implement the InjectConfig interface.

[aimuz]

Writing an external plugin
Wanting to be able to read/modify the PROJECT file (or any other file) that has been created by previous plugins from the external plugin

@everettraven Yes, I hope so.

[everettraven]

Taking a look back at this I had originally thought that just exposing the files via the universe would work for accessing the PROJECT file but I realize now that the PROJECT file doesn't get exposed via the same filesystem and is written after all plugins are run.

This means that we definitely need to expose a way for an external plugin to implement the InjectConfig function. I think we should attempt to follow a similar format as the one that exists for BindFlags and UpdateMetadata:

kubebuilder/pkg/plugins/external/init.go

Lines 34 to 40 in 014e08c

	func (p *initSubcommand) UpdateMetadata(_ plugin.CLIMetadata, subcmdMeta *plugin.SubcommandMetadata) {
	setExternalPluginMetadata("init", p.Path, subcmdMeta)
	}
	func (p *initSubcommand) BindFlags(fs *pflag.FlagSet) {
	bindExternalPluginFlags(fs, "init", p.Path, p.Args)
	}

[camilamacedo86]

HI @aimuz,

It seems that your question has been answered. To summarize, you can create your plugin using Kubebuilde as a LIB, and you would do it in the same way that the plugin is implemented in the Kubebuilder project. Regarding the PROJECT file, we recommend you track all input data as we do for the plugins provided by the CLI.

For further information see: https://book.kubebuilder.io/plugins/extending-cli.html

Therefore, I will close this one. However, if you still have questions, issues or suggestions, please feel free to raise new issues for each.