-
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
Use replacement syntax for patch #5063
Comments
cc @natasha41575 as the main author of replacements, but I believe we would prefer to address any shortcomings in Replacements rather than transferring the more complex syntax to the simpler patches transformer. If I understand correctly from the following:
part of the problem you have with using replacements is label selector support in targets. The good news is that already exists! Although it seems to be missing from the docs for some reason, it was introduced in #4229 and this test case is an example of how to use it: replacements:
- source:
kind: Deployment
name: deploy-1
fieldPath: spec.template.spec.containers.0.image
targets:
- select:
labelSelector: foo=bar-1
fieldPaths:
- spec.template.spec.containers.1.image The other shortcoming seems to be the need to source the replacement value from a resource:
One thing that is already possible is to put the /triage needs-information |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
Thanks, @KnVerey , both of your suggestions are perfect for my use case |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
Although the |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close not-planned |
@k8s-triage-robot: Closing this issue, marking it as "Not Planned". In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Re that, can you expand on this a bit more? Is this part of a larger intent to slowly deprecate It seems to me that so far, there was a clear semantic difference between patches and replacements:
Allowing replacements to support static inline values as source blurs the line between the two. Also users will logically expect the more expressive replacement syntax to also be usable for deleting values; which will not be possible with the suggested approach if I'm not mistaken. On the other hand, it would be possible if patches supported the more expressive replacement syntax. Don't get me wrong, I would like to see this capability added to kustomize but I want to make sure that there is a sound reasoning behind what should go into replacements, and what should go into patches. Otherwise we risk just having two competing APIs that do similar-things-but-not-really, and this will be quite confusing for users. |
Eschewed features
What would you like to have added?
I want to use the
replacement
syntax which is more powerful than thepatchesJson6902
but without using another resource as the source.I would like to rewrite this:
like this:
Why is this needed?
Keep the configuration cleaner, and leverage the
labelSelector
to patch multiple resources at the same time.Can you accomplish the motivating task without this feature, and if so, how?
I can achieve the same final result using replacement and ConfigMap
What other solutions have you considered?
Post kustomize variables substitution like Flux does [1]
Anything else we should know?
No response
Feature ownership
The text was updated successfully, but these errors were encountered: