-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
kustomize localize
command to pull all remote data
#3980
Comments
+1. Also could simplify access to private repos (requiring credentials) in some scenarios. |
@monopole I think this would be a fantastic addition to kustomize. We currently use All that to say, a kustomize-aware alternative to I think a key piece of functionality necessary to make this feature sucessful would be the ability to intelligently merge upstream changes with changes made in the local package (when the remote is a git repo, that is). This is something that |
If setters were changed to an on-the-fly transformer as discussed in #3953, then localize wouldn't be necessary in order to apply setter values to remote resources and merging on update wouldn't be necessary. I suggest that localize should just fetch, not merge, consistent with the existing fetch behavior during build. |
@bgrant0607 I definitely agree that applying setters on-the-fly is necessary as there should be no distinction between how setters (or any other functionality) behaves when referencing local vs remote resources. That being said, I did not mean to conflate this with our desire for kustomize-aware package management utilities in general. We have found that it is simply easier to build and maintain kustomizations on top of resources that are declared locally. Also, because remote references are inherently mutable in most cases, we find explicitly requiring a human in the loop when pulling upstream changes to be a desirable property. Ideally, something like
I see all of these use cases I'm describing as an extension of your statement in #3953:
I don't want to go off on too much of a tangent here, but I would like to summarize by adding that we are not super pleased with the direction
This is our primary motivation for wanting to see the |
We experimented with integrating cli-utils actuation commands into kustomize, but the command architecture didn't make sense from an experience point of view. Integrating cli-utils into kubectl as originally planned (kubernetes/enhancements#810) encountered other challenges. In the meantime, tools like Helm, Terraform, Pulumi, and dozens of others have already implemented their own mechanisms, as discussed in kubernetes-sigs/cli-utils#364 (comment), so the ship has kind of sailed. As for "package entrypoint", packaging is out of scope for Kustomize and for Kubernetes: |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
/assign |
@annasong20 and I are working internally on a proposal for this issue. I'm hopeful that we will have it ready in the next couple of weeks. |
Another reason localize may be useful: Remote bases may not work in some embedded uses of kustomize due to the git requirement: |
Linking it here so we don't forget: for alpha, we should define what it means to "not handle" the helm fields: #4933 (comment) |
Alpha version is done and will be available in the next release. Closing this now. |
Some kustomize uses cases preclude network use, so it would be nice to capture the raw material from remote sources but still retain the option of performing different builds.
So perhaps
would create a new directory (failing if it already existed), containing a localized, copied version of {target}, such that
would produce the same output, but the latter wouldn’t need the network to run.
The kustomization files under {newDir} would have their
resources:
fields rewritten to point to directories under {newDir}, named to not collide with any copies of {target} subdirectories. The contents of {newDir} would be the result of a graph traversal rooted at {target}.Likewise, the
helm
directive would be rewritten to download and use a local chart.See https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/helmchartargs.go
This feature would benefit from first implementing #3979
The text was updated successfully, but these errors were encountered: