-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make better use of kustomize bases #615
Comments
/kind feature |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/lifecycle frozen |
@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. |
/cc |
Hi @andres-de-castro,
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 |
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! |
HI @erikgb,
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
I agree with you Now, let's speak about this specific task/issue requirement:
So, what does it means? Are we here speaking about not provide all kustomize files?
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 |
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. |
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? |
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).
The text was updated successfully, but these errors were encountered: