replacement in base kustomization missing custom nameSuffix

pberndt commented 3 months ago

What happened?

When applying a custom nameSuffix to a base kustomization that is using replacements, some of the replacement values will be missing the nameSuffix.

What did you expect to happen?

I expected the replacements to consistently reflect the applied nameSuffix. Instead, in some cases they contain the suffix and in other cases they reference non-existent resources (without the suffix).

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

.
├── base
│   ├── 1-pv.yaml
│   ├── 2-pvc.yaml
│   └── kustomization.yaml
└── custom
    └── kustomization.yaml

# base/1-pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: tekton-cnb-pv  # will receive a custom suffix "-foo"
spec:
  storageClassName: ""
  claimRef:
    name: will-be-replaced  # => tekton-cnb-pvc (missing suffix!)

# base/2-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: tekton-cnb-pvc  # will receive a custom suffix "-foo"
spec:
  storageClassName: ""
  volumeName: will-be-replaced # => tekton-cnb-pv-foo (works as expected)

# base/kustomization.yaml
resources:
  - 1-pv.yaml
  - 2-pvc.yaml
replacements:
  - source:
      kind: PersistentVolume
      fieldPath: metadata.name
    targets:
      - select:
          kind: PersistentVolumeClaim
        fieldPaths:
          - spec.volumeName
  - source:
      kind: PersistentVolumeClaim
      fieldPath: metadata.name
    targets:
      - select:
          kind: PersistentVolume
        fieldPaths:
          - spec.claimRef.name

# custom/kustomization.yaml
resources:
  - ../base
nameSuffix: -foo

Then invoke

kustomize build custom

Expected output

apiVersion: v1
kind: PersistentVolume
metadata:
  name: tekton-cnb-pv-foo
spec:
  claimRef:
    name: tekton-cnb-pvc-foo
  storageClassName: ""
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: tekton-cnb-pvc-foo
spec:
  storageClassName: ""
  volumeName: tekton-cnb-pv-foo

(nameSuffix applied consistently)

Actual output

apiVersion: v1
kind: PersistentVolume
metadata:
  name: tekton-cnb-pv-foo
spec:
  claimRef:
    name: tekton-cnb-pvc
  storageClassName: ""
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: tekton-cnb-pvc-foo
spec:
  storageClassName: ""
  volumeName: tekton-cnb-pv-foo

(nameSuffix missing from PV's claimRef)

Kustomize version

v5.3.0

Operating system

Linux

k8s-ci-robot commented 3 months ago

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](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

k8s-triage-robot commented 2 weeks ago

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

Mark this issue as fresh with /remove-lifecycle stale
Close this issue with /close
Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

kubernetes-sigs / kustomize