Kustomize: Failed to find target with or without namespaces being specified 3.1.0

[karlmutch]

When using nested directories Deployments cannot be resolved by kustomize. This occurs with or without namespaces being specified and also when using both json and strategic merge patch types.

This appears to differ from other reported cases as the namespaces do not seem to influence the problem.

Given the following, when using the following command in the root directory and error occurs.

kustomize build

Error: accumulating resources: recursed accumulation of path 'test-kus/overlays/production': accumulating resources: recursed accumulation of path 'green': no matches for OriginalId apps_v1_Deployment|~X|esp-green; no matches for CurrentId apps_v1_Deployment|~X|esp-green; failed to find unique target for patch apps_v1_Deployment|esp-green

.
├── kustomization.yaml
└── test-kus
    ├── base
    │   ├── deployment.yaml
    │   └── kustomization.yaml
    └── overlays
        └── production
            ├── green
            │   ├── deployment.yaml
            │   └── kustomization.yaml
            └── kustomization.yaml

patch-issue.zip

Base deploy.yaml

at test-kus/base/deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: esp-green
spec:
  template:
    spec:
      containers:
      - name: esp
        imagePullPolicy: Always
        image: leaf/esp-service

Patching deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: esp-green
spec:
  template:
    spec:
      containers:
      - name: esp
        image: leaf/esp-service:latest

[jbrette]

@karlmutch Just adjust your green kustomization.yaml to include esp-green resource and it works fine as shown bellow. This environment to reproduce your issue is available here.

prompt$ kustomize version
Version: {KustomizeVersion:3.1.0 GitCommit:95f3303493fdea243ae83b767978092396169baf BuildDate:2019-07-26T18:11:16Z GoOs:linux GoArch:amd64}

$ kustomize build .

kind: Deployment
metadata:
  annotations:
    note: This is the production green environment
  name: esp-green
  namespace: test
spec:
  template:
    metadata:
      annotations:
        note: This is the production green environment
    spec:
      containers:
      - image: 11111.dkr.ecr.us-west-2.amazonaws.com/leaf/esp-service:latest
        imagePullPolicy: Always
        name: esp

[karlmutch]

Thanks for the really complete answer, this however leaves me with a dilemma for a more complex situation. This example has a blue and a green deployment at the same level.

.
├── kustomization.yaml
└── test-kus
    ├── base
    │   ├── deployment.yaml
    │   └── kustomization.yaml
    └── overlays
        ├── kustomization.yaml
        └── production
            ├── blue
            │   ├── deployment.yaml
            │   └── kustomization.yaml
            └── green
                ├── deployment.yaml
                └── kustomization.yaml

Changing each of the kustomize.yaml files to include the base results in a duplication error.


Error: accumulating resources: recursed accumulation of path 'test-kus/overlays': accumulating resources: recursed merging from path 'production/blue': may not add resource with an already registered id: apps_v1_Deployment|~X|esp-green


Leaving it out of any one of the green or blue Kustomize.yaml file results in the not found error within the peer directory it was omitted from.
Here is the use-case archive.

patch-issue.zip

I could imagine that there might be another way to use the base differently but I am not yet advanced enough at this early stage in my familiarity with the feature set kustomize offers to think of alternatives?

[karlmutch]

Am I simply duplicating https://github.com/kubernetes-sigs/kustomize/pull/1316 ?

[jbrette]

@karlmutch You are not duplicated #1316 is a very interesting use case where we are trying to compose service a lot like you would use git to merge and cherry pick patches. We have a beginning of solution of it.

For your more simple use case, I think it works: here

 kustomize build .

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    note: This is the production blue environment
  name: esp-blue
  namespace: test
spec:
  template:
    metadata:
      annotations:
        note: This is the production blue environment
    spec:
      containers:
      - image: 11111.dkr.ecr.us-west-2.amazonaws.com/leaf/esp-service:latest
        imagePullPolicy: Always
        name: esp
---
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    note: This is the production green environment
  name: esp-green
  namespace: test
spec:
  template:
    metadata:
      annotations:
        note: This is the production green environment
    spec:
      containers:
      - image: 11111.dkr.ecr.us-west-2.amazonaws.com/leaf/esp-service:latest
        imagePullPolicy: Always
        name: esp

[karlmutch]

@jbrette Thanks for this example, helped to get me understanding things.