📖 proposal for new plugin to generate code ( deploy-image.go.kubebuilder.io/v1beta1 )

[camilamacedo86]

Description

• EP/proposal to add a new plugin to generate the code requires to address the common needs

Motivation

• Many operators will at the end have CRD's which will represent a deployment/pod of an image:tag. So, I am as oper user I'd like to have a feature to make this process easier. Also, see that it address common requests such as Proposal: Images Sub-specification operator-framework/operator-sdk#2158
• Reduce the learning curve since users are able to generate the basic operator following the good practices via this feature which makes more intuitive understand how the things work and know-how to improve/develop their solutions.
• Address common questions over the basic features and how to for example; implement the tests, use envvars, RBAC permissions as watch features.
• Feature Request: Finalizer handler scaffolded by default for go/v3 #2010

[pwittrock]

/lgtm

[camilamacedo86]

HI @Adirio, @estroz,

It is updated by following your feedback and suggestions over its details in the implementation as well.
See that the idea here is to be a plugin which will works as addon / declarative one after we merge the solution described and discussed in #1941

[camilamacedo86]

/hold cancel

[Adirio]

Disclaimer: I didn't read thoroughly the implementation examples.

I agree with the goals of this EP. My two cents on the open questions at the end:

1. Should we allow to scaffold the code for an API that is already created for the project?
   I agree that we should require both the API and the controller to be created with the same command call as both parts are required for this plugin.

2. Should we support StatefulSet and Deployments?
   Starting with one and increasing the supported types incrementally sounds good to me.

3. Could this feature be useful to other languages or is it just valid to Go based operators?
   This plugin would mainly modify *_types.go and *_controller.go which are obviously only relevant for go based operators. In a future, if other languaged based operators are supported (either officially or by the community) this plugin could be used as reference to create an equivalent one for their language. Therefore, it should probably be a "subdomain" of go.kubebuilder.io

NIT: I think we need to come up with a better name for this plugin. Generate code seems pretty imprecise in a scaffolding project. The plugin is about good practices and image deploying. Do you like good-practices.go.kubebuilder.io or deploy-image.go.kubebuilder.io? I don't really like the first for a plugin name despite being descriptive.

[camilamacedo86]

Hi @Adirio,

Thank you for your comments and review. I adopted the name deploy-image.go.kubebuilder.io suggested and addressed your comments as well.

[Adirio]

Will let other mantainers the chance to take a look before merging, but LGTM

[estroz]

Overall lgtm, and I agree with the responses @Adirio has in #1803 (review).

A few things before I approve this proposal:

1. This proposal is dependent on at least phase 1.5, if not phase 2, plugins, so it can't be implemented or tested until the that requirement is complete.
2. Will this plugin live in the kubebuilder repo? I am ok with that, but the test matrix will start blowing up if more plugins are added. Something to be aware of. IMO I'd like to see a kubebuilder-plugins repo, with submodules for each plugin.

[estroz]

Since kubebuilder is only concerned with Go projects and the proposal discusses Go-only changes, I think the answer to this question is simply "no".

[camilamacedo86]

I would like to leave the answer to clarify some questions raised. This plugin is only valid for go. However, the same idea could be used as an example.

[estroz]

This configuration implies that phase 2 is required to implement this plugin, since the 1.5 proposal doesn't discuss adding plugin configs to plugins. @Adirio that's correct right?

[Adirio]

project-version v3 already supports that field. Nothing specific was defined for plugin phase 1.5 but it doesn't prevent it either. So I would say it doesn't require phase 2 (supporting external binaries is something we still haven't properly designed AFAIK) but it definetely requires phase 1.5.

[Adirio]

2. Will this plugin live in the kubebuilder repo? I am ok with that, but the test matrix will start blowing up if more plugins are added. Something to be aware of. IMO I'd like to see a kubebuilder-plugins repo, with submodules for each plugin.

Camila and me have already recognized the test matrix issue (there are already some permutations that we are not testing like plugin go/v2 with project-version v3) and adding plugins will make it even a greater issue. I already considered a separate repo (I called it kubebuilder-community but kubebuilder-plugins may be a better name).

[camilamacedo86]

Hi @Adirio, @estroz,

Camila and me have already recognized the test matrix issue (there are already some permutations that we are not testing like plugin go/v2 with project-version v3) and adding plugins will make it even a greater issue. I already considered a separate repo (I called it kubebuilder-community but kubebuilder-plugins may be a better name)

Will this plugin live in the kubebuilder repo? I am ok with that, but the test matrix will start blowing up if more plugins are added. Something to be aware of. IMO I'd like to see a kubebuilder-plugins repo, with submodules for each plugin.

This plugin address a need that has been requested in SDK for mone than one year. For example operator-framework/operator-sdk#2158. Also, it addresses a discussion made with @pwittrock as well in order to make the things easier for the end-users address the most common causes. So, this one would be born with "official/beta" support.

In the long term yes. However, see that currently, Kubebuilder has not too many plugins yet. And then, and the preliminary support for plugins did not indeed released.

In this way, at this moment, in POV it shows a little Premature Optimization care about it. Note that the issue #2016(plugin phase 2) will 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. Then, the discussion over the best approach to dealing with many plugins and if they should or not leave in the kubebuilder repository would be better addressed after that

Is it make sense? can we agree on that?

However, I will clarify it in the EP. Also, the other point raised by @estroz as well regarding its blockers.
Really thank you for your time on that

[estroz]

Despite the open issues, this is ok for now.

/lgtm

[k8s-ci-robot]

[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:

• OWNERS [Adirio,camilamacedo86,estroz]

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