Make better use of kustomize bases

[DirectXMan12]

We should see if we can make better use of kustomize bases, instead of scaffolding out resources every time. This could range from kustomize remote bases (which raise questions about trusting things on the internet) to vendoring a separate repository or directory with the bases (and not pruning non-go in that directory).

[DirectXMan12]

/kind feature
/priority backlog

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[DirectXMan12]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[DirectXMan12]

/lifecycle frozen

[bjmask]

@DirectXMan12 I typically never suggest using remote bases as you're at the mercy of the upstream resource to keep the git URI's intact. Furthermore it would be impossible to build on airgapped environments.

[Kavinjsir]

/cc

[camilamacedo86]

Hi @andres-de-castro,

Furthermore it would be impossible to build on airgapped environments.
I think you made a good point which I also go along within.

In this case, I think we can close this one as deferred.

@Kavinjsir @varshaprasad96 @everettraven @erikgb have your thoughts on this one?

Could we agree to close it?

[Kavinjsir]

Hi @andres-de-castro,

Furthermore it would be impossible to build on airgapped environments.
I think you made a good point which I also go along within.

In this case, I think we can close this one as deferred.

@Kavinjsir @varshaprasad96 @everettraven @erikgb have your thoughts on this one?

Could we agree to close it?

@camilamacedo86 I don't have hands on experience of kustomize remote basis so probably not able to evaluate the pros & cons in between. But I agree that we may close it for now. We may discuss later in case there are users mention it. (OR if necessary, I can keep track and try working with a PR.. 😃 )

[erikgb]

I think this could be a big improvement to kubebuilder! To be honest, the awkward re-scaffolding is the main reason for only partially adopting kubebuilder in the projects I maintain. I just went through an upgrade from v3 to v4 in one of my projects using https://book.kubebuilder.io/migration/migration_guide_gov3_to_gov4.html, and it was really painful....

And the argument about air-gapped environments is not valid IMO. Kubebuilder is a CLI tool, and not a build tool AFAIK. And supporting developer workstations in air-gapped environments is not something I think we should take into account. I am also bothered by working in air-gapped environments, so I think I have some experience in this area. 😅 I have more issues with the code scaffolded by kubebuilder in air-gapped environments. Examples: setup-envtest and Dockerfile.

Finally, I don't see using remote Kustomize bases as any worse than installing a Helm chart from a Helm repository. And I prefer Kustomize over Helm any day!

[camilamacedo86]

HI @erikgb,

I think this could be a big improvement to kubebuilder! To be honest, the awkward re-scaffolding is the main reason for only partially adopting kubebuilder in the projects I maintain. I just went through an upgrade from v3 to v4 in one of my projects using https://book.kubebuilder.io/migration/migration_guide_gov3_to_gov4.html, and it was really painful....

This one will not sorted out this problem. The hard part to upgrade is not related to the kustomize files but the go ones were is expected have code implementation on top. Also, I would say that what makes most hard those upgrades are customizations and changes made in the layout of what is scaffolded by default in general. If the project does not have changes in the default layout then is possible to just re-scaffold all, diff and add the code on top again.

To try add a helper for this need we have the idea: #2895

And the argument about air-gapped environments is not valid IMO. Kubebuilder is a CLI tool, and not a build tool AFAIK. And supporting developer workstations in air-gapped environments is not something I think we should take into account. I am also bothered by working in air-gapped environments, so I think I have some experience in this area. 😅 I have more issues with the code scaffolded by kubebuilder in air-gapped environments. Examples: setup-envtest and Dockerfile.
Finally, I don't see using remote Kustomize bases as any worse than installing a Helm chart from a Helm repository. And I prefer Kustomize over Helm any day!

I agree with you workstations in air-gapped environments is not something I think we should take into account
However, Kubebuilder help authors to build the project but we have none features to help them to distribute the project to their users. Helm provides features for that. That is another gap that I think we could be looking to see if we can address. (outside of the scope of this issue)

Now, let's speak about this specific task/issue requirement:

We should see if we can make better use of kustomize bases, instead of scaffolding out resources every time. This could range from kustomize remote bases (which raise questions about trusting things on the internet) to vendoring a separate repository or directory with the bases (and not pruning non-go in that directory).

So, what does it means? Are we here speaking about not provide all kustomize files?
If so:

• a) how users can do things on top?
• b) Would that affects how users distribute the projects today?
• c) How projects like Operator-SDK can do their own customizations on top of kubebuider default scaffolds? How kubebuilder can be used as lib to help the community build their own plugins and helpers on top?
• d) What infra kubebuilder would need to have to provide the support for that?
• e) What kustomize manifests scaffolded by kubebuilder would never be changed by users?
• f) What is the real value to address this? Would the effort to achieve this goal and keep it maintained pays off?

If someone, would like to propose a solution for this goal I think the best approach would to be push a PR with a PE https://github.com/kubernetes-sigs/kubebuilder/tree/master/designs so we can discuss the technical details, the impacts, the pros and cos and etc. WDYT?

PS.: I believe that was tracked a long time ago and before we move forward with the plugin ecosystem, to allow kubebuilder be used as lib and etc. Also, that shows for me that config-gen initiative could be a new project like "KubeGen" that moves in this direction, see: #3000

c/c @Kavinjsir

[camilamacedo86]

This issue was discussed today in the community meeting. It seems that it is not clear to us how that would work, so if someone is interested in this one, we would love to receive a proposal https://github.com/kubernetes-sigs/kubebuilder/tree/master/designs to discuss its details.

However, we decide to remove the freeze. If nobody from the community comes back with a proposal solution to achieve this goal after some time, the bot will close this issue automatically.

[camilamacedo86]

Hi @erikgb,

It is still not clear to us how to achieve the goal. However, if you would like to push a PR or Enhance the Proposal with a solution to do this one, that would be very welcome.

Your points regarding envtest being something that will not work by default in airgap env are not sure if is a good argumentation because it is only valid for dev purposes and would not be used as the kustomize to delivery the solution. Could you please let us know more about your thoughts one how this one would work?