I'm trying to understand your initial requirement here. What do you mean with "additional" processing?

I'm trying to understand your initial requirement here. What do you mean with "additional" processing?

In the example (additional processing) means I do load some vars files.

Regarding patch: Understand today, the deployment.yml must be one folder above the kustomization.yml code (they can't co-exist in the same folder).

I will post some example this week. Assume I have some "shared" folder ("to/some") with generic service deployment that I will refer from some deployment.yml. As it's shared and might have multiple variants it's used, I dont want to be limited to only "path: to/some" (with kustomize.yml) but I either want to be flexible to do "include: so/some" (and have some more control with another layer of deployment.yml).

For a good reason I dont want to structure my folders "to/some/kustomization" just because deplyment.yml must be one folder above, so it can by path: ./xxx refer the place where kustomization.yml is.

minor fix force-pushed in..

The way I understand you is that you want to have a shared kustimization with a set of shared variables attached to it, all while NOT having the kustomization below a sub-deployment (with just a deployment.yaml and the vars). Is this correct?

I'm not sure that his is worth the additional effort and risks being introduced. For example, the templating engine currently expects to work on deployment-item (a kustomization) level, meaning that it renders the whole directly in one go. At the same time, the deployment.yaml from a sub-deployment is rendered as a single file.

When we start to mix sub-deployments with deployment-items, we'd start to render files multiple times. This can easily lead to unexpected behaviour.

Based on what I wrote before: Right now, it is not explicitly forbidden to mix deployment-items and sub-deployments, it simply fails at some point. This should also be re-considered.

Well you made good point. Certainly I little experiment with structuring the repo/model input for kluctl.

First aimed to two approaches:

• have directory with reusable config/examples/deployment files that I could share independently
• define on vars (all interpolated params + possibly helm values & kustomization overrides)

That's why is required for simplicity. I anyway have workaround for the below as path: ../<folder name> but that is not that nice as:

deployments:

• path: .

To answer you problem with mixing sub-deployments. Yes I have hit that (they just render once, or render each time depends how configured). And you are right this is not good pattern. Today I dont mix subdeployments and if then it;s for different target/cluster.

The reason for "experiment with structuring the repo/model input" is that I tend to have configuration parameters (vars) somewhere at top level, rather then partially in each deployment.yml across several folders for these reasons:

• having full config (vars) down the last included deployment.yml is sort of "helm-values" like approach. Almost as hardcoded, still require some control params, interpolation and if/else in templates.
• having full config (vars) down the last included deployment.yml does not play well if I want to share some params across multiple apps.
• ^^ in both examples, one can move params up in the repo hiearchy and introduce new params for interpolation. That is pretty much ok in many example. I only have that experience it tend to "creative params/variables" model like structures that are uniq per deployment - thus not reusable. Thus rather pushing myself to structure all paramas "top level" and in the structure the application use it (helm-values, helm-lib values, my own interpolation, my own kustomization patches).

Top-down approach requires me to introduce some "patch" that will to "all" apps introduce some certain config (like ingress config or storageClass/persistence setup). While application deployment code remains simple, prone to extra templating, having space for others to reuse my "app deployment example" on their deployments with (their overrides) without having to deal with resources they dont need or interpolation/params they are not interested with.

(as mentioned, will share some deployment repo with you this week, possibly we could have some short zoom call to discuss)

will share some deployment repo with you this week

@codablock pls check "non-working" export from "working" setup":
https://github.com/epcim/gitops-infra-public/tree/main/cluster/apealive

will share some deployment repo with you this week

@codablock pls check "non-working" export from "working" setup": https://github.com/epcim/gitops-infra-public/tree/main/cluster/apealive

This is what is requested to work:
https://github.com/epcim/gitops-infra-public/blob/main/cluster/apealive/hass/deployment.yml#L3

looks like I will need to rebase this..