Documentation unclear: Flux Kustomization patches do not apply over nested kustomizations

[ondrejkolin]

We use following kustomizations structure in our projects:

kustomize.config.k8s.io/v1beta1 -> kustomize.toolkit.fluxcd.io/v1 -> kustomize.toolkit.fluxcd.io/v1 -> helmrelease

In my setup I have a patch on all top-level flux kustomizations with a patch for all helm releases - full kustomization file.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- gotk-components.yaml
- gotk-sync.yaml
- kustomization-in-the-middle.yaml
patches:
  - target: 
      kind: Kustomization
      group: kustomize.toolkit.fluxcd.io
      version: v1
    patch: |
      - op: add
        path: /spec/patches
        value:
          - target:
              kind: HelmRelease
            patch: |-

The patch is not delivered to the HR. This makes sense as when I do flux trace on that HR, it's only dependend on it's parent kustomization.

Altough documentation mention writing patches at top-level Flux kustomization as a feature used in bulk shard assignment:

For example, assuming you want to assign a tenant to a particular shard, in the root Flux Kustomization that reconcile the tenant’s Flux sources, kustomizations and Helm releases label these resources as follows:

Image is a screenshot of the code from the documentation

I think that the documentation is wrong. I have a very minimal example where it's not working: https://gitlab.com/ondrej.kolin/flux-helmrelease-patch-test

[ondrejkolin]

IDEA: Recursive patches for kustomize.toolkit.fluxcd.io?
something like:

patches:
  - target:
    kind: Potato
    recursive: True
    patch: ... 

Could validate it's able to do the recursion on the target resource (if it's supported by the target API) ...

Best to my understanding (not much) the native kustomize patches are recursive.

[shanewhite97]

I really like this idea, I am also trying to do nested patches, here is my example below:
`- patch: |

• op: add path: /spec/patches
• value:
  • patch: |-
    • op: add path: /spec/chart/spec/sourceRef
    • value:
      kind: GitRepository
      name: zarf-charts
      target:
      kind: HelmRelease
      target:
      kind: Kustomization
      namespace: flux-system`

DISCLAIMER, ignore indentation, our company doesn't allow pasting

[iAnomaly]

I would also really stand to benefit from a recursive patching feature.

We have a similar nested kustomization tree:

Kustomization/acme-system/acme-app
├── Namespace/acme-system
├── Kustomization/acme-system/api-controllers
│   ├── HelmRelease/acme-system/api
│   └── HelmChart/acme-system/api
├── Kustomization/acme-system/ui-controllers
│   ├── HelmRelease/acme-system/ui
│   └── HelmChart/acme-system/ui
└── GitRepository/acme-system/infrastructure

We're following the multi-tenancy model from https://github.com/fluxcd/flux2-multi-tenancy and https://github.com/controlplaneio-fluxcd/d1-fleet which requires patching HelmRelease and Kustomization resources:

1. serviceAccountName
2. targetNamespace

patches:
    - patch: |-
        kind: _
        metadata:
          name: _
        spec:
          serviceAccountName: flux
          targetNamespace: acme-system
      target:
        kind: (HelmRelease|Kustomization)

But...this only applies to the first layer/depth down. Any HelmRelease or Kustomization resources the next level down or deeper won't be patched. To get those we have to expand the patch as follows and would have to continue doing so for each layer of depth:

patches:
    - patch: |-
        kind: _
        metadata:
          name: _
        spec:
          serviceAccountName: flux
          targetNamespace: acme-system
          patches:
            - patch: |-
                kind: _
                metadata:
                  name: _
                spec:
                  serviceAccountName: flux
                  targetNamespace: acme-system
              target:
                kind: (HelmRelease|Kustomization)
      target:
        kind: (HelmRelease|Kustomization)