Tool allow users choose between --project-version "2" or "3-alpha"

[camilamacedo86]

The tool allows users to choose between --project-version "2" or "3-alpha", however, both will perform the same GO v2 plugin scaffold. The only diff between both is the project name that is added to the PROJECT file now because of what was done in kubernetes-sigs/kubebuilder#1611 which would be valid just for v3-alpha.

• Should not the 3-alpha project-version scaffold the project with SDK plugin alpha based on the default upstream Go plugin for 3-alpha?

[camilamacedo86]

Hi @joelanford, @estroz,

Probably we might be able to check/address it after 1.0, however, in POV it is valid just think a little about it and the possible impacts of this change after 1.0 to make sure that everything is fine.

[estroz]

Users should be able to choose between the two supported project versions. Until project version 2 is deprecated, --project-version 2 is still valid. The project version and plugin version are orthogonal concepts; one just happens to be scaffolded by the other. Since deprecation of a project version is a fully upstream issue (the SDK gets PROJECT from kubebuilder), the issue of 2's deprecation should be recreated upstream.

[camilamacedo86]

Hi @estroz,

Sorry, I think you misunderstood the concern raised here.

The point is that in upstream when we choose --project-version=3-alpha it will use the default plugin for this version which is NOT the same behaviour with SDK as a dev might expect.

See that we could also have a v3-alpha plugin based on the v3-alpha KB plugin for SDK as well.
Also, note that Kubebuilder does NOT scaffold v2 plugin for v3-alpha project by default as SDK.

So my concerns relevant for 1.0 are:

if we have the intention to add v3-alpha plugin for sdk and have both tools aligned:

• Are we ok about to do that after 1.0 or it would cause some impact on the projects generated already?
• If no, should we not hidden the v3-alpha and keep the v2 as default?
• Also, could we not be impacted in the future with project version = v3-alpha with changes as that one done in the PR pkg/plugin/v2: use config project name if project version is v3+ kubernetes-sigs/kubebuilder#1611? Are we ok with?

PS.: in POV we can align both and have an sdk-v3-alpha plugin as well which will be based in the v3-alpha-kb plugin, the default plugin should be the stable instead and of the alpha one and it is fine to be done after 1.0 which means that in this case this task would be kept open add assign to another milestone.

I hope that it clarifies my concerns.

WDYT @joelanford

[joelanford]

@estroz @camilamacedo86 can you clarify one thing for me? My understanding is:

• project version v2 supports and is inherently equal to Kubebuilder's Go v2 plugin. v2 projects do not support the layout or plugin keys. So if someone runs operator-sdk init --project-version="2", that results in the _exact_ same output as kubebuilder init --project-version="2"`

• project version v3-alpha is required for Helm and Ansible layouts AND for our phase2-ish go.sdk.operatorframework.io plugin. With this, users get the extra bundle and samples kustomization in Go projects and they get access to Helm and Ansible layouts.

Is this understanding correct?

[camilamacedo86]

Hi @joelanford and @estroz

OK. I also re-checked all to see if I am not missing the boat in anything here.

See $ operator-sdk init -h (== in both tools )

--project-version string project version, possible values: ("2", "3-alpha") (default "3-alpha")

If we run $ operator-sdk init or operator-sdk init --project-version=3-alpha: (default "3-alpha")

SDK == KB

• PROJECT version 3-alpha with layout: go.kubebuilder.io/v2 and plugins:go.sdk.operatorframework.io/v2-alpha:
• It will add the projectName in the PROJECT file since we merge pkg/plugin/v2: use config project name if project version is v3+ kubernetes-sigs/kubebuilder#1611 ( add projectName when the project version is v3-alpha )

If we run $ operator-sdk init --project-version=2: (NOT Default)

SDK != KB

• SDK will have PROJECT version = 2 and to do the same scaffold done with the v3-alpha but has not the projectName
• KB has no plugins and layout in the project file.

PS.: I am unable to gen with version 2 in sdk with the master branch: See: #3690

Regards my comments over v3-alpha plugin: I was missing the boat since KB do NOT use the go.kubebuilder.io/v3-alpha by default in the v3-alpha projects as well. To gen that we need to pass the plugin version as well.

So, the only think that we need to do in this task is after fix #3690 ensure that if we run operator-sdk init --project-version=2:

• It will not scaffold layout and plugins in the PROJECT file.
• And then, it also should not perform the SDK customizations.

Am I right?

[estroz]

Plugin	Plugin Phase	Plugin Version	Project Versions
go.kubebuilder.io	1	v2	2, 3-alpha
go.kubebuilder.io	1	v3-alpha	3-alpha
go.sdk.operatorframework.io	2	v2-alpha	3-alpha
ansible.sdk.operatorframework.io	1	v1	3-alpha
helm.sdk.operatorframework.io	1	v1	3-alpha

I use plugin phase to differentiate the current phase 1 plugins from future phase 2 plugins, which we have implemented as post-plugin modifiers (manifests, scorecard) in a forwards-compatible way under the go.sdk.operatorframework.io umbrella plugin. I think this is where the confusion lies, since this umbrella plugin cannot be seen in operator-sdk init -h output as a phase 1 plugin; this is intentional because phase 2 plugins are not implemented yet and we don't know what their CLI selection process will look like nor can/should we modify how the --plugins flag works.

[camilamacedo86]

Hi @estroz, @joelanford

The following one is not supportable by SDK just for KB currently. Am I right? Would we like to support it as well as post 1.0?

go.kubebuilder.io	1	v3-alpha	3-alpha

Regards the project-version=2:

go.kubebuilder.io	1	v2	2, 3-alpha

• Should the PROJECT file scaffolded by SDK has the plugin and layout which are values that do NOT exist KB for this project version?
• Since project-version=2 actually do not support plugins would not make more sense we do not scaffold a plugin on it at all? I mean, should not it be better/simpler if we do not support project v2 and have not this option at all? See : FATA[0005] failed to initialize project with version "2" #3690

[camilamacedo86]

I understand that the scenario project-version=2 will be solved with https://github.com/kubernetes-sigs/kubebuilder/pull/1628/files 👍

[estroz]

Closed by #3697