Hi, team. I was brainstorming an idea but I'm having some trouble with the execution. I'm just wondering if this seems do-able. We use Atmos + Terraform to build everything. We run almost exclusively on K8s, mostly via Kustomize and ArgoCD. Injecting dynamic information from our Terraform into Kustomize can be a bit awkward at times. So, I had the following idea with Atmos: • Create inline manifests with Kubernetes components. These manifests would actually be Kustomization files (either resources or components/patches). • I would deploy these manifests to some dedicated branch in the repository that contains our other Kustomize manifests. • I would configure the appropriate Kustomize configurations to "include" this dedicated branch as-needed. • Example. I need to inject a security group ID created by some Terraform into an annotation or configmap somewhere. I could have an inline manifest (Kustomize patch) that gets deployed to a pre-determined location in the dedicated branch. Then the appropriate Kustomize configurations can "include" that manifest rendered and deployed by Atmos. Problem is, I'm having some trouble choosing the file name. I often need the generated manifest to be called

kustomization.yaml

, but it seems like the name might be automatically generated. Is it possible to override this behavior? I saw the

split

setting for rendering, but I didn't see something similar when deploying an inline manifest.

If you need Atmos to generate a file by a different name, that'd be something that we should make configurable

Yes, I was, in fact, using the git commit functionality for this experiment. So, I had this in a stack: (...if anyone is wondering why I included

metadata.name

in a Kustomize file, it's because Atmos errors out otherwise...)

kubernetes:
    gitops:
      provision:
        targets:
          deployment-repo:
            kind: git
            repository: config-repo
            path: "kustomize/overlays/{{ .vars.environment }}/kustomization.yaml"
            commit:
              message: "Render manifests for {{ .vars.environment }}"
      vars:
        region: "{{ .vars.aws_region }}"
      manifests:
        - apiVersion: kustomize.config.k8s.io/v1beta1
          kind: Component
          metadata:
            name: cert-manager
          patches:
            - target:
                kind: "ClusterIssuer"
                name: "letsencrypt-dns"
              patch: |
                - op: add
                  path: /spec/acme/solvers
                  value:
                    - dns01:
                        cnameStrategy: Follow
                        route53:
                          region: "{{ .vars.region }}"
                          hostedZoneID: "{{ atmos.Resolve "!terraform.state route53 public_zone_id" }}"

And the repository mentioned was configured like so:

git:
  repositories:
    config-repo:
      uri: REDACTED
      branch: terraform-patches
      clone:
        depth: 1
      commit:
        signing: auto
        author:
          name: atmos[bot]
          email: atmos-bot@acme.com
      push:
        retries: 3
      init:
        keep_history: false

Then I ran this:

atmos kubernetes deploy gitops --stack $STACK_NAME --target deployment-repo

You can hopefully see that the idea here was to be able to create Kustomize patches that are dynamically generated by our IaC. Usually I would need to update the Kustomize configurations for cert-manager manually with the Route53 zone ID or have Terraform deploy the ArgoCD Application with a patch. This nearly worked. The problem is, Kustomize cannot include a remote configuration without a

kustomization.yaml

file. But it seems I'm unable to configure the desired name of the file that gets rendered and committed to the repository. In the above example, it actually created a directory called

kustomization.yaml

and then a random file name within there (I say "random", but I'm guessing there's a certain logic to it). Of course, I assume no one thought to use this functionality this way (I certainly hadn't).

Thanks, that's helpful context and I was able to reproduce the bug

Awesome! Yeah, like I said, I can't decide if it's a good idea...but it feels like a pretty good idea. The "bridge" between Terraform/Tofu and ArgoCD has always been a tad awkward whenever you need to get information from one to the other. I think this approach would be very attractive to any groups heavily invested in Kustomize.