kustomize: patches should throw error on missing targets

Describe the bug

If kustomize build is run with a patchesJson6902 section specifying a nonexistant target it still reports success and outputs its resources as if it worked

Files that can reproduce the issue

kustomization.yaml (note the ‘v2’ in the version field)

kind: ""
apiversion: ""
resources:
- manifests/servicemonitor.yaml
patchesJson6902:
- target:
    group: monitoring.coreos.com
    kind: ServiceMonitor
    name: starboard-exporter
    namespace: starboard
    version: v2

  path: jsonpatches/patch.0.yaml

manifests/servicemonitor.yaml

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    app: starboard-exporter
  name: starboard-exporter
  namespace: starboard
spec:
  endpoints:
  - path: /metrics
    port: metrics
  selector:
    matchLabels:
      app.kubernetes.io/instance: starboard-exporter
      app.kubernetes.io/name: starboard-exporter

jsonpatches/patch.0.yaml

- op: add
  path: /metadata/labels/release
  value: kube-prometheus-stack

Expected output

Some kind of error e.g, “WARNING: patchesJson6902[0] target not found for $target - please check kustomized resources for correctness” or “ERROR: patchesJson6902[0] target not found for $target! Bailing out.” An exit code > 0 to signal that something went wrong Some suggestions of partial matches e.g., “Found $similartarget, did you mean $targetdiff?”

Actual output

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    app: starboard-exporter
  name: starboard-exporter
  namespace: starboard
spec:
  endpoints:
  - path: /metrics
    port: metrics
  selector:
    matchLabels:
      app.kubernetes.io/instance: starboard-exporter
      app.kubernetes.io/name: starboard-exporter

Kustomize version

❯ kustomize version
{Version:kustomize/v4.4.1 GitCommit:b2d65ddc98e09187a8e38adc27c30bab078c1dbf BuildDate:2021-11-11T23:27:14Z GoOs:darwin GoArch:arm64}

Platform

❯ sw_vers
ProductName:    macOS
ProductVersion: 11.6.2
BuildVersion:   20G314

About this issue

Original URL
State: open
Created 2 years ago
Reactions: 6
Comments: 16 (8 by maintainers)

Most upvoted comments

After further discussion with @KnVerey @natasha41575, in light of use cases like https://github.com/kubernetes-sigs/kustomize/issues/4379#issuecomment-1343471388 and @Arabus’ suggestion https://github.com/kubernetes-sigs/kustomize/issues/4379#issuecomment-1344205011, we’ve decided to make the error-throwing upon finding no matching target configurable.

For patches, we will add a field (named along the lines of) allowNoTargetMatch under options that, when “true”, prints a warning to stderr instead of throwing an error. The default value of this field will be “false”.

For the deprecated patchesJson6902, we will throw an error, as it does not have an options field to configure and we aren’t looking to grow a deprecated field.

annasong20 on Mar 23, 2023

Considering that section 4 of https://www.rfc-editor.org/rfc/rfc6902 states that nonexitent target object MUST be an error but section 5 states:

If a normative requirement is violated by a JSON Patch document, or
   if an operation is not successful, evaluation of the JSON Patch
   document SHOULD terminate and application of the entire patch
   document SHALL NOT be deemed successful.

It might be a good tradeoff to make this configurable and set the default to fail.

SN: I concede it makes your code less Dry to state every affected object OTOH it also makes it less explicit and prone to overmatching.

Arabus on Dec 9, 2022

I think this issue deserves more attention; patchesJson6902 was already difficult to debug before 😉

lwille on Feb 22, 2022

@hjannasch - I started looking into it and will update my PR #4715 soon.

laxmikantbpandhare on Jun 16, 2023

Any news on this topic? Would be nice have this option in the near future.

hjannasch on May 23, 2023

While I agree there is definitely a reason to want Kustomize to fail if it does not make an intended patch, I believe this should be behavior that is configurable rather than a hard requirement.

The behavior of not failing if a patch is not applied is a feature of the patchesJson6902 that allows you to create components that apply patches to resources if those resources exist but not fail if they do not. If, for example, there were multiple resources that a URL could be added to, with the current behavior of the patchesJson6902, you can create a general purpose component to add this URL to every type of resource instead of needing to specify the resource being used in the overlay.

Remove this functionality entirely would force my Kustomize code to be much less DRY

iNoahNothing on Dec 8, 2022

/triage accepted /retitle patches should throw error on missing targets

We discussed this during the bug scrub, and have arrived at the decision that patches, patchesStrategicMerge, and patchesJson6902 should all throw an error in the case of a missing target rather than silently doing nothing.

natasha41575 on Jul 6, 2022

The ability to detect/fail on missing targets would greatly benefit CI/CD Kubeval pipeline jobs, was shocked to see that this doesn’t happen currently.

eponymz on Apr 12, 2022