When using an simple overlay with a namePrefix on a base that contains replacements the prefix does not end up on the target values.

[natasha41575]

See the test in #4031.

   EXPECTED                         ACTUAL
   --------                         ------
   apiVersion: apps/v1              apiVersion: apps/v1
   kind: Deployment                 kind: Deployment
   metadata:                        metadata:
     name: prefix-target              name: prefix-target
   spec:                            spec:
     template:                        template:
       spec:                            spec:
         containers:                      containers:
X        - image: prefix-source           - image: source
           name: nginx                      name: nginx
   ---                              ---
   apiVersion: apps/v1              apiVersion: apps/v1
   kind: Deployment                 kind: Deployment
   metadata:                        metadata:
     name: prefix-source              name: prefix-source
   spec:                            spec:
     template:                        template:
       spec:                            spec:
         containers:                      containers:
         - image: nginx:newtag            - image: nginx:newtag
           name: nginx                      name: nginx

[natasha41575]

/assign

[natasha41575]

Closing this issue. After taking a closer look I believe this is intended behavior.

[rjferguson21]

@natasha41575 I'd like to provide another example to illustrate similar behavior that I believe breaks user expectations and would make it very difficult to maintain a reusable base that contained replacements.

base/kustomization.yaml

namespace: base-namespace
configMapGenerator:
  - name: bluecm
    literals:
      - color=blue
  - name: redcm
    literals:
      - bluenamespace=base-namespace
replacements:
- source:
    kind: ConfigMap
    name: bluecm
    fieldPath: metadata.namespace
  targets:
  - select:
      name: redcm
    fieldPaths:
    - data.bluenamespace

kustomization.yaml

resources:
  - base
namespace: overlay-namespace

This yields:

apiVersion: v1
data:
  color: blue
kind: ConfigMap
metadata:
  name: bluecm-747dfcb89d
  namespace: overlay-namespace
---
apiVersion: v1
data:
  bluenamespace: base-namespace
kind: ConfigMap
metadata:
  name: redcm-mfbbg4gd6c
  namespace: overlay-namespace

I can appreciate that this is a difficult problem to solve, but I think it creates a bit of a mine field for the user when using replacements in a base. In our use case we have an overlay that is applied on all of our application deployments that sets things like the namePrefix and namespace. Our assumption would be that the application's base could exercise the replacements functionality without fear of a downstream overlay doing something that would compromise the functionality by utilizing features like namespace.

[natasha41575]

Thanks for following up! I will keep this issue open because the use case is compelling, and I agree that it will be good to track changes to a resources GVKNN wherever we can.

I will also reopen your PR and leave a comment if you would like it to be merged.

[seh]

My #4099 (comment) and #4099 (comment) speak to a similar desire and expectation.

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[k8s-triage-robot]

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

This bot triages issues and PRs 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:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

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

This bot triages issues and PRs 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:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close

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/test-infra repository.