-
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
kustomize edit fix needs to split multi-doc SMP patches into multiple files #5040
Comments
Also hit by this. Only workaround I have found is to explicitly specify patch targets in kustomization.yaml, but that a ton of refactoring for patches targeting multiple resources by name. |
/retitle kustomize edit fix needs to split multi-doc SMP patches into multiple files The problem here is that /assign @brianpursley |
IMO, splitting into multiple files is worse, even if they are kept in a subdirectory. I have to create multiple patch lines, I have to open multiple files when changes are correlated, etc. Nothing about this is an improvement over the existing behavior of patchStrategicMerge. It does not seem terribly difficult to transform an existing SM patch, so why can't we keep the functionality? What if it was something like: patches:
- path: my-multi-sm-patch.yaml
target: { byGVKN: true } |
That's an interesting idea; please open a separate issue for the feature request. One thing to address is the fact that the patch file could contain a JSON patch, which does not include GVKNN information. |
GI'm having a very similar problem with an even more minimal example. Do you think it's the same bug? I'm running # kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- cm.yaml
patches:
- patch: cm.patch.yaml # cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: cm # cm.patch.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: cm
data:
foo: bar $ kustomize build .
Error: trouble configuring builtin PatchTransformer with config: `
patch: cm.patch.yaml
`: unable to parse SM or JSON patch from [cm.patch.yaml] It works fine if I change the # kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- cm.yaml
patches:
- patch: |-
apiVersion: v1
kind: ConfigMap
metadata:
name: cm
data:
foo: bar |
If you agree that this is the same bug as I experience, then this has nothing to do with multi-doc SMP patches. In that case, we should rename the Issue to something like "patch cannot take file path as argument". |
@lindhe Is Can you change your kustomization.yaml to use
|
Yep, that works! Thanks a lot, I was pulling my hair not understanding why it didn't work. And as per usual it was a typo. :D |
I just found this issue after running Turned out I needed to split each resource patch in its own file and things started to work. This is a very cryptic error message: |
any updates for this ? |
Also hit by this, i wanted to set replica count of a deployment using patches and its giving same error |
For reasons described in #5059 (comment), I don't think this is needed anymore, as multi-doc SMP patches are now allowed under |
I have a similar issue and only managed to solve it like this :
it complains about my cronjobs.yaml , if I put it under patches like the rest it fails like this and it does not process the rest of files :
My cronjobs.yaml contains multiple cronjobs in the same files , they aren't templated due to differences , I know its terrible but its staging and production is the same so is there any way ? |
Hi there, @mo-dayyeh! Could you please file a separate issue and add a minimal example that allows us to reproduce the problem so we can investigate it? |
|
What happened?
I've tried my existing kustomize manifests with kustomize 5.0.0 and found a problem. I applied kustomize edit fix, but kustomize build command returns error:
What did you expect to happen?
Kustomize build returns:
How can we reproduce it (as minimally and precisely as possible)?
Expected output
Actual output
Kustomize version
5.0.0
Operating system
Linux
The text was updated successfully, but these errors were encountered: