JSON patch add operation should add to list instead of overwriting the list.

[Juastin]

Eschewed features

• This issue is not requesting templating, unstuctured edits, build-time side-effects from args or env vars, or any other eschewed feature.

What would you like to have added?

We would like the - op: add operation to automatically append a new item to an existing list, rather than overwriting the entire list.

Currently, when using - op: add in a Kustomize patch, it only adds a new item when no list is predefined in the YAML. If the list already exists (e.g., for volumes), the operation overwrites the entire list instead of appending the new item.

Why is this needed?

The current approach requires managing multiple patch files to handle cases where lists are either predefined or need to be added. This creates unnecessary complexity, making the configuration harder to maintain and more prone to errors.

Introducing a feature that automatically appends new items to an existing list, instead of overwriting or requiring separate patches, would simplify the process and reduce boilerplate code. This improvement would make Kustomize more efficient and easier to work with, especially for common Kubernetes resources that need dynamic modifications.

Can you accomplish the motivating task without this feature, and if so, how?

Yes, it is possible, but it requires using multiple patch files to handle the case where a list may or may not already exist.
Currently, we are using two separate patch files to manage these scenarios for our volumes and volumeMounts:

1. Patch when no volumes or volumeMounts are predefined:

- op: add
  path: /spec/template/spec/volumes
  value:
    - name: tmp
      emptyDir: {}
- op: add
  path: /spec/template/spec/containers/0/volumeMounts
  value:
    - name: tmp
      mountPath: /tmp

2. Patch when volumes and volumeMounts already exist, in order to append new items to the list:

- op: add
  path: /spec/template/spec/volumes/-
  value:
      name: tmp
      emptyDir: {}
- op: add
  path: /spec/template/spec/containers/0/volumeMounts/-
  value:
      name: tmp
      mountPath: /tmp

This approach adds unnecessary complexity and requires maintaining multiple patches to handle both scenarios. A feature that allows appending to existing lists using a single patch would simplify our configuration.

What other solutions have you considered?

We’ve tried using StrategicMergePatch, but it has limitations. Specifically, it requires specifying the container name to apply changes, which introduces complexity when working with multiple deployment scripts. The need to explicitly define the container name prevents the patch from being dynamically applied across different configurations, making it less flexible for our use case.

Anything else we should know?

No response

Feature ownership

• I am interested in contributing this feature myself! 🎉

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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-sigs/prow repository.

[sda399]

that's a jsonpatch rfc limitation (kustomize does not implement jsonpach but uses a lib for it)

As a workaround, did you try to set an empty array for those objects in your base, so you can retain only one patch, with /- syntax?

[Juastin]

that's a jsonpatch rfc limitation (kustomize does not implement jsonpach but uses a lib for it)

Okay, what's the library? Then I can post the issue there.

The empty array is basically the problem. If you want to dynamically add a couple of items to a list you would have to add empty lists to every base, adding unnecessary code.

[sda399]

lib: gopkg.in/evanphx/json-patch.v4
I doubt the lib wants to diverge from the rfc: https://www.rfc-editor.org/rfc/rfc6902

[Juastin]

Hmm, that's a shame.. Thanks anyway.