beekhof/flex.diff

OK - I read this differently, initially. I read it as "we should offer the ability to have different override values for the "global" pattern variables we normally set in the pattern framework. So, I definitely see a use for that if you want to refer to a different URL than the "self" repo (for lack of a better term; the gitops repo that primarily drives the pattern).

But upon looking at this more closely, it's clear that this approach would be allowing us to change the names of the overrides, and I'm struggling a bit to see a reason we'd want to do that. It would have to be a scenario where we want one of the "implicit" values we set, but the name of the override for it would have to change. (And, that would be exclusive of using the usual name of the override.) Which might be weird.

So, I can see why this might be helpful for domain (in particular, but possibly in an "additiive" way), for example:

- name: global.localClusterDomain
  value: {{ coalesce $.Values.global.localClusterDomain $.Values.global.hubClusterDomain }}
- name: {{ .domainField }}
  value: {{ coalesce $.Values.global.localClusterDomain $.Values.global.hubClusterDomain }}

And I think in practice we'd want to conditionalize it so that if not .domainField the section gets skipped entirely. The idea might generalize like this:

{{- range .domainFields }}
- name: {{ . }}
  value: {{ coalesce $.Values.global.localClusterDomain $.Values.global.hubClusterDomain }}
{{- end }}

Which avoids a lot of (imo) ugly conditionals, while still allowing multiple overrides per field, and not violating a potential user expectation about variables the pattern sets implicitly.

I see potential of mischief if we wind up undefining the clusterdomain variables in particular; several patterns use those, and I could definitely see those being co-opted into other charts in this way. (It's a neat dodge, allowing for the manipulation of values without actually templating the values file itself).