Kustomize 2.x breaks patch re-use

[jgonera]

I commented on #798 but that issue is already closed so perhaps nobody is looking at it anymore.

The solution proposed in #798 doesn't work for me (or I don't understand how to apply it). My folder structure:

.
├── base
│   ├── config-maps
│   ├── kustomization.yaml
│   └── resources
│       └── app.yaml
├── common
│   ├── patches
│   │   └── debug.yaml
└── overlays
    ├── dev
    │   ├── config-maps
    │   ├── kustomization.yaml
    │   ├── patches
    │   └── resources
    ├── prod
    │   ├── config-maps
    │   ├── kustomization.yaml
    │   ├── patches
    │   └── resources
    └── stage
        ├── config-maps
        ├── kustomization.yaml
        ├── patches
        └── resources

Now let's say I use common/patches/debug.yaml in both overlays/dev/kustomization.yaml and overlays/stage/kustomization.yaml like this:

bases:
- ../../base
patchesStrategicMerge:
- ../../common/patches/debug.yaml

That patch applies a change to the resource defined in base/resources/app.yaml so I can't create another base (e.g. /base-debug) and put the patch there because then I will get the following error:

Error: AccumulateTarget: failed to find an object with apps_v1_Deployment|app to apply the patch

I suppose this happens because a base can't apply a patch to a resource defined in another base. How can I solve this? I don't want to have a copy of debug.yaml in both overlays because the content would be exactly the same.

[JordanP]

I guess you could use a symbolic link ?

[jgonera]

@JordanP symbolic links are not cross-platform and I'd rather avoid them in my git repos.

@monopole do you have any suggestions? I see that this restriction was introduced in #700 and the fix mentioned there does not say what we could do if we want to patch something that is already coming from a base.

[pohly]

@JordanP symbolic links don't work, the security check resolves the link and then complains about the target.

I also ran into this limitation. The only solution that I see right now is to duplicate files in my git repo, which is just plain ugly.

[monopole]

Thanks, yes - its a problem.

The data path restrictions imposed in #700 have the unintended effect of blocking the reuse of patch files. #700 doesn't create a problem for resources, as the way to achieve resource reuse is through bases (different kustomizations can refer to the same base). A base is also a way to reuse generated resources like secrets and config maps, so #700 doesn't block generator reuse.

But patches are transformers. We can allow their reuse via the new transformers plugin notation (which will allow base-like addressing kubernetes/enhancements#931) - or via a flag that disables the Loader restrictions.

[monopole]

In the meantime, duplicate the patches. Annoying, but symbolic links are disallowed.

[frejsoya]

This is a similar to #868. We ended up restructuring the file layout with make in a shared deployment/setup glue. But from a user perspective it is now a black magic box.

[monopole]

I'm taking this.

[monopole]

Please see the new FAQ.

[galindro]

@monopole Regarding this issue: I've the same restrictions pointed by @jgonera. To temporary fix this (without duplicating patch files), I've installed the head version (today) of kustomize by doing:

go get -v sigs.k8s.io/kustomize
go install sigs.k8s.io/kustomize

After that, I've used the flag --load_restrictor none proposed in the FAQ for disable the path restriction imposed by #700. But, unfortunately, it doesn't works, trowing this error:

Error: accumulating bases: recursed accumulation of path './app-group': accumulating bases: recursed accumulation of path './myapp': failed to find an object with apps_v1_Deployment|myapp to apply the patch

Here is my current directory structure:

├── base
│   ├── app-group
│   │   ├── kustomization.yaml
│   │   └── myapp
│   │       ├── deployment.yaml
│   │       └── kustomization.yaml
│   └── kustomization.yaml
└── overlays
    └── dev
        ├── app-group
        │   ├── kustomization.yaml
        │   └── myapp
        │       ├── deployment.yaml
        │       └── kustomization.yaml
        └── kustomization.yaml

All the mentioned file structure could be downloaded from here, for test proposes.

The command that I've issued was: kustomize build --load_restrictor none ${PWD}/overlays/dev

Do I need to open a new issue?

[jsravn]

@galindro it works for me. Are you sure your patch is correct?

I don't really agree with the restriction though. It prevents the only way to do patch reuse. If people are downloading kustomize projects off the internet and running them on production clusters without understanding what they do or trusting the source, they have much bigger problems imo. If this restriction won't be removed - maybe kustomize could whitelist certain folders to allow shared patches, or something like that.