📖 Plugin Phase 2 Enhancement Proposal

[rashmigottipati]

Description of the change
This PR adds an enhancement proposal for Kubebuilder Phase 2 Plugins

Signed-off-by: Rashmi Gottipati chowdary.grashmi@gmail.com

[k8s-ci-robot]

Hi @rashmigottipati. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[rashmigottipati]

/cc @estroz @Adirio @jmrodri

[k8s-ci-robot]

@rashmigottipati: GitHub didn't allow me to request PR reviews from the following users: jmrodri.

Note that only kubernetes-sigs members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

/cc @estroz @Adirio @jmrodri

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.

[jmrodri]

A few items to clarify.

[jmrodri]

I think we need to add more details on the following:

• what the potential structure looks like being passed in. I would start with assuming JSON format.
• think about the messages we can send to the plugins? i.e. get_flags or register, init, create_api, create_webhook, these will be part of the message being sent. Each of these will have their own set of parameters and return values. The plugin implementer should be able to handle some or all of these, at a minimum get_flags or register.

[jmrodri]

Interestingly enough, a lot of what we're talking about here reminds me of CORBA.

[jmrodri]

@estroz made a good point when he mentioned security regarding the environment. @rashmigottipati What's our answer for security of the plugins? For example, do we prevent or care if someone has malicious code that we could run arbitrarily? Do we need a signature for plugins that can be verified? Or do we leave that up to the user that installed the plugin that they have verified it is from a known source and they have chosen to install it?

[estroz]

Lots of cleanup needed.

Another issue has come to mind too: what happens when an external plugin wants to run a generator on some files it added to the universe? It cannot write those files itself since the universe wouldn't reflect the file's actual state, and it cannot run the generator if the files don't exist on-disk. I think some sort of post-plugin hook (executable) could be added to the PluginResponse struct so kubebuilder can execute it after writing the universe to disk. This hook executable would be in the same directory as the external plugin itself, but the plugin executable name would be different (specified in the PluginResponse). Thoughts?

[jmrodri]

@rashmigottipati quick nit for the overview. Apply @estroz comments and I will re-review again. I agree with eric's additions but it's hard to reconcile until they have been applied.

[rashmigottipati]

@estroz What do you think about adding a GeneratorPath field in the PluginResponse struct that specifies the path to the executable that Kubebuilder will need to execute post Run? Not all plugins would need to run generators on files, so if a plugin does not set this field, specifying the omitempty option will exempt that field from encoding if it has an empty value.

[rashmigottipati]

After having an offline discussion with @estroz, we decided to implement the post plugin hooks in follow-ups.

[jmrodri]

A couple things and suggestions.

[jmrodri]

/lgtm

[k8s-ci-robot]

@jmrodri: changing LGTM is restricted to collaborators

In response to this:

/lgtm

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.

[estroz]

One small fix, otherwise lgtm! Will label after you push the change.

[estroz]

/ok-to-test

[estroz]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: estroz, jmrodri, rashmigottipati

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:

• OWNERS [estroz]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment