Ensure extraValuesFiles entries are properly rendered

[sector2000]

No description provided.

[mbaldessari]

What's the use case here? Reason I ask is because tpl is a bit finnicky on spoke clusters (because the template is rendered on the hub by argo+acm and then pushed to the spokes)

[sector2000]

Why are you referring to the spoke clusters? The extraValueFiles is used in the Apps of the hub cluster. I see that the the way the extraValuesFiles are being rendered is inconsistent between extraValuesFiles at global level and at application level. The extraValueFiles at application level is being rendered through tpl, while the ones at global level are not. Am I maybe misunderstanding the usage of the extraValueFiles? They I intended to use it is to ad a list of valuefiles to all the deployed applications in the hub cluster, where they should be additionally prefixed with $patternref if being used in a multisource app.

[mbaldessari]

So the clustergroup chart gets also rendered on spoke clusters via the acm-chart (in this same org), but when this happens that rendering happens on the hub cluster and then the clustergroup app gets pushed to the spokes, so it gets rendered with the hub values.

Not against it per se, just wondering what the actual use case is given that sharedValueFiles also exists (and suffers from the same problem on spokes)

[sector2000]

Ok I see it. I guess this is one of the reasons why the value files are divided by platform type, groups and OCP version. Because the spoke clusters can be very diverse.
Let's see if I understand it correctly. The global.sharedValueFiles are additional value files that are pushed to all application, no matter if it's on the hub or spoke. The clusterGroup.extraValuesFiles are pushed to all apps of the corresponding clusterGroup (hub, group-one and so on). If my understanding is correct, maybe using clusterGroup.sharedValuesFiles instead of clusterGroup.extraValuesFiles would help to understand that they are the same, just in a different context. Using clusterGroup.applications.<appname>.extraValuesFiles look fine instead because they are actually additional value files valid only for a specific app only.

This being said, I think the way the value files are pushed to the apps should be consistent, so either all rendered or none of them. If rendered, the values of each clusterGroup will control what the result will be.