I suspect this works in the very simple case, but won't work if a user uses either the sharedValueFiles or the other values-files mechanism in clustergroup/acm-chart/pattern-operator to do any overrides in the clustergroup (like we did for ESO downstream in MCG some time ago or how IE does it currently)?

@mbaldessari That is exactly right. It's tricky to get a helm render of everything from another cluster; my immediate alternative was to only declare elements for spokes in the hub clustergroup, which felt really really wrong. This mechanism, while not fully general, gets a bit further in that regard.

My thought is that for a properly general solution we would "harvest" the imperative configmaps from the spoke clusters. That way we could be sure about about how local things like clusterDomain, platform and so on are rendered, and potentially introspect some of those things, even, if we need them. A "harvester" could gather the configmaps into a predictable spot, and add labels and/or annotations for filtering. It would still be tricky to render individual Application objects for the same reasons; it might make sense to "harvest" those too. That's as far as I've thought about it so far.

@mbaldessari That is exactly right. It's tricky to get a helm render of everything from another cluster; my immediate alternative was to only declare elements for spokes in the hub clustergroup, which felt really really wrong. This mechanism, while not fully general, gets a bit further in that regard.

My thought is that for a properly general solution we would "harvest" the imperative configmaps from the spoke clusters. That way we could be sure about about how local things like clusterDomain, platform and so on are rendered, and potentially introspect some of those things, even, if we need them. A "harvester" could gather the configmaps into a predictable spot, and add labels and/or annotations for filtering. It would still be tricky to render individual Application objects for the same reasons; it might make sense to "harvest" those too. That's as far as I've thought about it so far.

Yeah it's a stupidly hard problem with the constraints we have. Just a quick thought (today I am a bit strapped for time), but what if we just get out of this problem entirely for now while we think of nice ways to address this and simply offer a way for the user to custom configure the vault. So something like this validatedpatterns/layered-zero-trust@59b8519. This way the user puts the needed config aspects for his vault and we sidestep this more complex architectural issue for the time being but still have a way to get SS_CSI fully working. In the meantime we can try and explore ways to make things a bit more automatic and have more pieces of vault magically autoconfigured. Would this be a crackpot initial stab at this? @day0hero @darkdoc

Agreed on the inherent complexity of the problem. Even if we do wind up gathering all the clustergroup-level config that doesn't necessarily net us the Application objects, which would probably also want (to be fully general). And even if we do something like that, it would be deeply magical, and that by itself gives me some pause. I think it makes a lot of sense to have a generic vault config injection system that can be used on the hub in conjunction with the existing imperative stuff as a relief valve (I have at least one more use case to add, for AAP, but it's not critical), and then (eventually) work on a comprehensive auto-magic system. I suspect we're saying the same thing @mbaldessari . wdyt? (also @day0hero @darkdoc )