-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Create documentation for migrating from deprecated (removed in 5.0.0) patchesStrategicMerge
to patches
#5052
Comments
I fully support this since I ran into this issue today: #3481 (comment) |
I have noticed the following changes.
|
Just so we are on the same page: the Ideally, the migration path is simple: you run /triage needs-information |
Correct, and when using I guess this is tracked here #5049 |
looked for a while to do the migration, in my scenario, it's simple, just from you can find more on the official website: https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/patches/ |
I tried it with |
I'm experiencing exactly the same behavior. |
@schlichtanders @cyberslot you mention using kustomize bundled with kubectl ( |
@sbocinec Personally, I've tried both ways without success.
|
Same for me,
|
Same issue with same versions |
How would one now handle semantically "empty" apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization Building a base that references this file yields an error:
The file and folder hierarchy is still needed for legacy reasons. |
Have you tried turning this into a component? |
|
The `patchesStrategicMerge` keyword has been deprecated for a while [1]; we should be using the `patches` keyword for both strategic merge and JSONPatch patches. [1]: kubernetes-sigs/kustomize#5052
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 |
/remove-lifecycle stale |
same issue : / |
This thread is pretty dead, but figured I'd chime in. I used to have all my strategic merge patches under the First thing I did was change the key to be
Once I change the key and run
Turns out, I had to add the
So, once i split out my patch file so it was only 1 patch per file, my error went away and everything was gravy (no
|
I had the same problem and solved it as below. before
after
If I delete the "path" keyword, the error below occurs.
Ref |
No idea how to use error: specify one path to kustomization.yaml |
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 |
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 |
Eschewed features
What would you like to have added?
Create documentation that explains how to transition from using
patchesStrategicMerge
andpatchesJson6902
to usingpatches
Why is this needed?
We use
patchesStrategicMerge
extensively. I have read several issues that say that patches is a superset ofpatchesStrategicMerge
andpatchesJson6902
, but I am yet to come across a document that explain how to the exact same outcome using thepatches
directive. Since the old ones have been deprecated, some documentation on how to migrate would be useful.Can you accomplish the motivating task without this feature, and if so, how?
Yes, if someone could tell me here in this issue how use
patches
in order to do what I previously did withpatchesStrategicMerge
What other solutions have you considered?
None.
Anything else we should know?
No response
Feature ownership
The text was updated successfully, but these errors were encountered: