Nested component with reused component weird behavior

[CreMindES]

What happened?

I want to duplicate a resource with a suffixed name and some extra fields. This is not exactly a well documented use case, but in theory with the use of Components it should be possible.

My thought process was that I cannot just have the same component included twice as it would result in an identifier collision, so I have to sort of pre-render it inside a component - that should be more-or-less self-confined to my understanding with a big asterisk - and include that template component with slight modifications, e.g. nameSuffix, inside a wrapper component twice.

Folder structure

• components
  • service
    • service-a
      • kustomization.yaml
    • service-b
      • kustomization.yaml
    • kustomization.yml Component
  • service-template
    • kustomization.yml Component
    • service.yaml
• patches
  • dev
    • kustomization.yaml
    • service-a-patch.yaml
    • service-b-patch.yaml
• resources
  • configmap.yaml (irrelevant)
  • kustomization.yaml

This works nicely miraculously, whether I modify both name from the "template" component, or only one rendering the resources.

But if I want to apply patches in dev, it only works, if I modify both names and set up the patches according, i.e. target app-a and app-b, and it fails with
Error: no resource matches strategic merge patch "Service.v1.[noGrp]/app.[noNs]": multiple matches for Id Service.v1.[noGrp]/app.[noNs]; failed to find unique target for patch Service.v1.[noGrp]/app.[noNs] if app and app-b is the target while only addig a -b suffix to service-b in the component.

If I start reasoning from the fact that name suffixes are applied after patches, then the patch should target app always, so the component shall indeed be pre-rendered at that stage. But then if the component is pre-rendered, there should be no name collision. It's like if the template component and the wrapper would exists at the same time in the system intermittently. It also didn't work with patching the name, which should render in the same time if my previous reasoning is flawed in the order or self encapsulation.

What did you expect to happen?

I would expect the following order:

1. Wrapper component makes the included 2 Kustomization render
2. Each Kustomization inside the wrapper Component would render the template component
3. Each Kustomization inside the wrapper Component would run any remaining transformers, e.g. nameSuffix, patch.
4. From here, the standard Kustomize use case unfolds, where the resources rendered with the patches/dev with the now pre-rendered component(s) on top of it, effectively merging the two.

In other words, I would expect it to work with only renaming one of them as well.

How can we reproduce it (as minimally and precisely as possible)?

https://github.com/CreMindES/kustomize-5821

Expected output

apiVersion: v1
kind: ConfigMap
metadata:
  name: config
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: app
    dev: foo
  name: app
spec:
  clusterIP: None
  selector:
    app: app
  type: ClusterIP
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: app
    dev: bar
  name: app-b
spec:
  clusterIP: None
  selector:
    app: app
  type: ClusterIP

Actual output

Error: no resource matches strategic merge patch "Service.v1.[noGrp]/app.[noNs]": multiple matches for Id Service.v1.[noGrp]/app.[noNs]; failed to find unique target for patch Service.v1.[noGrp]/app.[noNs]

Kustomize version

5.4.3

Operating system

Linux

[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.

[CreMindES]

I'm also happy to add a test case, but first I wanted to clarify if this is intended behavior and I'm missing something or this is indeed a bug.