Extract config/base plugin valid for any language/type from Golang

[camilamacedo86]

What do you want to happen?

A plugin base which would be responsible to scaffold what is common for any kind of plugin no matter the language and what be integrated with KB and use it's as a consumer. ( basically, it is the hack and config directory since the PROJECT file is scaffold by the CLI )

It would allow the community to create any language/type plugin using the same base/config defined by KB in order to ensure its compatibility and maintainability see operator-framework/operator-sdk#2745 the requirements/problems that also could be addressed with:

• Make SDK use the real plugin system instead of having to do “hacky” wrappers around the go.kubebuilder.io plugin. To SDK Helm/Ansible plugins it would actually mean only implement what which is specifically for its types which means that SDK project would no longer need to copy and paste the config directory boilerplates from kubebuilder in order to do the same.
• It could allow we init hybrid operators such as; layout: config/v1,helm/v1,go/v3 which would have the init scaffold of all plugins. See: Support hybrid operators operator-framework/operator-sdk#670
• Solve the concerns issues raised in the WIP [SDK] - Proposal to split Helm/Ansible on their repos operator-framework/enhancements#44 regarding the risks of the language plugins deviated too much from the upstream base and to keep they maintainable.

Is there currently another issue associated with this?

This issue would be a follow up of #1991 and #1941

backwords compatibility

In order to ensure the backwords compatibility if we call the init command by informing only a plugin that is not the base config, the CLI needs to scaffold the base + the config as it is done currently. E.g operator-sdk init --plugins=helm/v2 will scaffold the base+helm

[camilamacedo86]

Hi @Adirio,

I tracked the issue regarding the scenario that we spoke about.

wdyt @estroz @DirectXMan12

[camilamacedo86]

The idea proposed regarding the project has a config-gen that also might able to address these requirements. See: #1831. We probably also might able to replace the base/config with the config-gen when it is stable. c/c @pwittrock

[camilamacedo86]

As we discussed today; before we decide to move forward with this or not we need first have a better position over #1831:

• shows that @pwittrock like the idea of adding a sample ( e.g project-v3-config-gen in the testdata which would be == project-v3 but using config-gen for we have better clarity of how it will work, what is covered or not by it and etc)
• my (@camilamacedo86) concerns is regarding the UX to apply customizations on the file. However, maybe config-gen also can write them in the disk instead of only allow patches.

So, it is blocked by we check out the config-gen final stage in KB to address all concerns about it first.

[camilamacedo86]

After the controller-tool meeting, this topic was discussed with @pwittrock, @DirectXMan12 and @Adirio, where I understand that we reach a consensus that:

The config-gen(#1831) shows a great idea and has the potential to address these needs. @pwittrock idea is to add the config-gen as alpha to allow it to be tested, used and improved until it reaches the desired maturity. However, it still in the initial phase, and we cannot know how long it will take.

IMO:

Decouple the config/ dir (kustomize) as suggested here is a good strategy for we can indeed try to replace it in the golang plugins in the future by the config-gen.

We need to define if we will release 3.0.0 before or after the changes: #2043. However, after these changes, this option shows be able to be achieved with a low effort.

So, it still the best approach discussed so far to allow us to move forward, make it easier for the other tools which consume KB as lib keep their many plugins maintained, as to allow others create plugins that are compatible with SDK/KB for any language/stack or indeed which are only "wrappers" as please them and also to try to find a way to use config-gen in the future and try to keep the backwards compatibility.

[camilamacedo86]

Just to clarify it is blocked by 1.5.

[camilamacedo86]

Following the result of a PR made in the past to check if would be possible try to centralize the config for the language types in SDK.

PR: https://github.com/operator-framework/operator-sdk/pull/3815/files

What are the caveats?

For Ansible:

• (ADD) - Scaffold a dir: See: https://github.com/operator-framework/operator-sdk/tree/master/testdata/ansible/memcached-operator/config/testing
• (CHANGE) because of an ansible issue: Add resource limits to Ansible operator scaffolding operator-framework/operator-sdk#3573 we need to remove the resources from the manager.yaml
  For Ansible/Helm: (CHANGE) Customized RBAC

The idea here would be addressed the caveats for the languages in the language plugins. After scaffold, the default config, just runs in the ansible/helm init plugin the customs on top which are what is very specific for them. So, it would show similar to the approach that we might need to address in the future with config-gen.

[camilamacedo86]

It also solves the scenario: operator-framework/operator-sdk#4542 for example.