Replacement file from different folder

[nice-pink]

Is your feature request related to a problem? Please describe.

I have multiple web apps which all use the same base and basically just change the name of the deployment, service, mapping, etc. This is a wonderful situation for replacements I thought. So I just need to patch the name of the deployment and use it as source for all replacements. So I avoid all the patches in the kustomization.yaml. I defined a replacement.yaml, changing all the values I wanted, but then found out that the replacement.yaml needs to be inside the overlay folder. I completely understand and support, that only values below in the tree of kustomizations are changed, but it would be nice to share a replacement file between overlays.

Describe the solution you'd like

Treat replacements like components and make them possible to grab from a different folder somewhere in the repo.

Describe alternatives you've considered

Adding symbolic link folders to each overlay is a pretty ugly.

Repo structure

- base
  - webapp
    - deployment.yaml
    - service.yaml
    - kustomization.yaml
- overlay
  - webapp-a
    - kustomization.yaml (patching the name of deployment, calling replacment with deployment name as source)
  - webapp-b
    - kustomization.yaml (patching the name of deployment, calling replacment with deployment name as source)
  - ...
- replacments
  - webapp

[k8s-ci-robot]

@nice-pink: 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/test-infra repository.

[jamesloosli]

I'm having this same experience as well. I've got a canned set of replacements that I keep copy-pasting into kustomization.yaml for several services.

I attempted to create a transformer using the replacements transformer, but I'm getting some odd results.

Here's what I tried;

# service-a/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

bases:
  - ../base

transformers:
  - ../transformers

# transformers/name.yaml
apiVersion: builtin
kind: ReplacementTransformer
metadata:
  name: name-transformer
source:
  kind: Deployment
  fieldPath: metadata.name
targets:
  - select:
      kind: Deployment
    fieldPaths:
      - spec.template.spec.containers.0.serviceAccountName
    options:
      create: true
...

After running kustomize build, the field serviceAccountName is never populated. When I put the same replacements directly in kustomization.yaml for a given service-a, I get the results I expect.

[jamesloosli]

After some shuffling, and sticking closer to the the documentation I ended up with a security warning.

Here's what I tried;

# service-a/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

bases:
  - ../base

replacements:
  - path: ../replacements/image.yaml
  - path: ../replacements/name.yaml

error message;

"Replacements:
- path: ../replacements/image.yaml
  source: null
  targets: null
- path: ../replacements/name.yaml
  source: null
  targets: null
`: security; file 'somepath/replacements/image.yaml' is not in or below 'somepath/service"

This seems to be a rough user experience. I have simple replacements to populate a particular string through some manifests, and I'd like those manifests to be reusable. After the amount of time I've put in it looks like I may have been better served with a templating tool rather than using kustomize.

[jamesloosli]

As with most things, I should have read the documentation further. --load-restrictor=LoadRestrictionsNone let me reference a standard set of replacements that were used across all of my services.

[el-mail]

Kustomize Components can be used instead of --load-restrictor=LoadRestrictionsNone