Support optional `components`/`patches` in kustomize applications (similar to `ignoreMissingValueFiles` for helm)

[VannTen]

Summary

Having the possibility to define an application with optional spec.source.kustomize.components/patches[] items.

Motivation

Here is my usecase: I use an applicationSet to define a set of (mostly) common apps over several clusters. Some of those apps are Helm charts, some are kustomize base, etc.
I need to have common settings at different "generalization levels" (currently : global, zone, prod_level, cluster-specific).
All of my apps are defined in a git repository and have the following structure

app
├── clusters
├── prlvl
└── zones

Where all of clusters,prlvl,zones are optional.
This works well with helm apps with the following template:

        template:
          metadata: {}
          spec:
            destination: {}
            project: default
            sources:
            - repoURL: "{{ repository }}"
              targetRevision: "{{ version }}"
              chart: "{{ chart }}"
              helm:
                releaseName: "{{ values.application }}"
                ignoreMissingValueFiles: true
                valueFiles:
                  - "$values/{{ values.application}}/values.yml"
                  - "$values/{{ values.application}}/zones/{{ values.zone }}/values.yml"
                  - "$values/{{ values.application}}/prlvl/{{ values.prlvl }}/values.yml"
                  - "$values/{{ values.application}}/clusters/{{ values.cluster }}/values.yml"
            - repoURL: "<REDACTED>.git"
              targetRevision: feat/merged_config
              ref: values

However, I'm not sure how to make that works in a similiar way for kustomize apps. My current template:

        template:
          metadata: {}
          spec:
            destination: {}
            project: default
            source:
              repoURL: "<REDACTED>.git"
              path: "{{ values.application }}"
              targetRevision: feat/merged_config
              kustomize:
                components:
                - zones/{{ values.zone }}
                - prlvl/{{ values.prlvl }}
                - clusters/{{ values.cluster }}

But this trigger a Sync error when one the components is missing.

N.B : both template are part of one applicationSet, and attached to top-level generators (which are pretty involved themselves, but that's not relevant to that part, I think).

Proposal

I think ignoreMissingValueFiles is a good candidate to use as an example. The application controller could check if the components / patches exists before passing them to kustomize edit, and prune them out if they don't.

FYI, this is the message with my current template:

ComparisonError
Failed to load target state: failed to generate manifest for source 1 of 1: rpc error: code = Unknown desc = Manifest generation error (cached): `kustomize edit add component zones/phm prlvl/pr clusters/prsatk8s` failed exit status 1: Error: zones/<REDACTED> has no match: must build at directory: not a valid directory: evalsymlink failure on '<path to cached source>/google-site-verif/zones/phm' : lstat <path to cached source>/google-site-verif/zones: no such file or directory Usage: kustomize edit add component [flags] Examples: add component {filepath} Flags: -h, --help help for component Global Flags: --stack-trace print a stack-trace on error

[crenshaw-dev]

Just at a glance, I think I'd be opposed to adding functionality that isn't present in the underlying tool (Kustomize). I'd recommend asking for the feature upstream and then we can look at exposing it in Argo CD.

[VannTen]

Just at a glance, I think I'd be opposed to adding functionality that isn't present in the underlying tool (Kustomize). I'd recommend asking for the feature upstream and then we can look at exposing it in Argo CD.

That's not the case for ignoreMissingValueFiles though ? Helm does not have any capacity to ignore missing values files, does it ?

[crenshaw-dev]

Ah! You're 100% correct, I didn't realize that.

I'm still loathe to depart from plain Kustomize behavior, but maybe I'm overly cautious.

[donovanrost]

This would make it easier to follow the GitOps bridge pattern demonstrated here https://github.com/gitops-bridge-dev/gitops-bridge-argocd-control-plane-template for the cases where it might not make sense to use helm

[bradkwadsworth]

This would be a very beneficial. I'm running into the same situation where I want to use Kustomize and components to create a custom deployment for a cluster if that custom component exists that matches the remote server name. Could it be as easy as logging a debug message if the kustomize edit add components command fails?