nested namePrefix configuration behaviour

[penekk]

What happened?

Let me begin with that I'm not entirely sure this is actually a bug but considering the unintuitive nature of this behaviour I'll go with that.

In order to get my point across let's consider this simplified (in a proper scenario there would be for example more 'bars' and more resources) structure:

Case 1:

apps/foo
├── bar
│   ├── ingress.yaml
│   ├── kustomization.yaml
│   ├── prefixed-resources.yaml
│   └── service-account.yaml
├── generators.yaml
├── jobs.yaml
├── kustomization.yaml
├── prefixed-resources.yaml
└── secrets.enc.yaml

and relevant files:

❯ cat apps/foo/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namePrefix: foo-
namespace: apps
resources:
  - bar
  - jobs.yaml
generators:
  - generators.yaml
configurations:
  - prefixed-resources.yaml

❯ cat apps/foo/bar/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namePrefix: bar-
namespace: apps
resources:
  - service-account.yaml
  - ingress.yaml

❯ cat apps/foo/prefixed-resources.yaml
namePrefix:
  - path: metadata/name
    kind: Job

❯ cat apps/foo/jobs.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: migrations
spec:
  template:
    spec:
      containers: []

In foo there's a namePrefix with explicit config for kinds and in bar there is namePrefix applied on everything.

This results in for example Job: migrations having prefixed applied twice:

---
apiVersion: batch/v1
kind: Job
metadata:
  name: foo-foo-migrations
  namespace: apps
spec:
  template:
    spec:
      containers: []

Case 2:

The difference compared to Case 1 is we do not apply prefix to Job resources in foo but decide to apply it to Job resources in bar:

❯ cat apps/foo/prefixed-resources.yaml
namePrefix:
  # - path: metadata/name
  #   kind: Job
  - path: metadata/name
    kind: Secret

❯ cat apps/foo/bar/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namePrefix: bar-
namespace: apps
resources:
  - service-account.yaml
  - ingress.yaml
configurations:
  - prefixed-resources.yaml

❯ cat apps/foo/bar/prefixed-resources.yaml
namePrefix:
  - path: metadata/name
    kind: IngressRoute
  - path: metadata/name
    kind: ServiceAccount
  - path: metadata/name
    kind: Job

Which results with Job: migrations having prefix applied once but with value 'from another namePrefix configuration' (so to speak):

---
apiVersion: batch/v1
kind: Job
metadata:
  name: foo-migrations
  namespace: apps
spec:
  template:
    spec:
      containers: []

What did you expect to happen?

Case 1: Job should have prefix foo applied once.

Case 2: Job should not have any prefix applied.

Perhaps I'm misunderstanding something fundamental over here but I would've expected to be able to have a granular control over prefix transformer used but things are gettin mixed/confusing here.

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

.

Expected output

No response

Actual output

No response

Kustomize version

v5.4.1

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.

[sda399]

Hi,
my thoughts

by definition: "NamePrefix will add a prefix to the names of all resources mentioned in the Kustomization file including generated resources such as ConfigMaps and Secrets."

So namePrefix adds a prefix to all metadata/name paths and the references to these modified names -- references searched in a list of predefined 'default' paths.
for custom paths we use transformerconfigs.

Case1

metadata/name transformation is expected, but there is also a config for it, so it modifies it again, we end up with double prefix.

Case2

metadata/name is transformed, by definition of namePrefix.

Examples

#! /bin/sh

[ ! -d foo ] || rm -r foo
mkdir -p foo/bar

cat <<EOF > foo/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namePrefix: foo-
namespace: apps
resources:
  - bar
  - jobs.yaml

configurations:
  - prefix-conf.yaml
EOF

cat <<EOF > foo/jobs.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: migrations
spec:
  custom-name-path0: migrations
  custom-name-path1: migrations
EOF

cat <<EOF > foo/prefix-conf.yaml
namePrefix:
  - path: metadata/custom-name-path
    kind: Job
    create: true
  - path: spec/custom-name-path1
    kind: Job
    create: true

EOF

cat <<EOF > foo/bar/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namePrefix: bar-
namespace: apps
EOF

cat <<EOF > expected.yaml
apiVersion: batch/v1
kind: Job
metadata:
  custom-name-path: foo-
  name: foo-migrations
  namespace: apps
spec:
  custom-name-path0: migrations
  custom-name-path1: foo-migrations
EOF
#---
kustomize build foo > result.yaml
printf "%-64s%s\n" expected.yaml result.yaml
printf "%130s\n" " " | tr ' ' '-'
diff -W130 -y expected.yaml result.yaml