Consider "nested" bundle support

[wryun]

Something like :bindsecret in refs could allow looking into bundles inside bundles.

This could simplify autowiring in Voyager and make bundle structure clearer? (thought bubble)

[ash2k]

It will either reduce concurrency (now we need to wait until the whole bundle is ready before we proceed with things that depend on it) OR it will require us to flatten the bunle-in-bundle-in-bundle... into a single tree. I don't see how either of these options is better than the status quo?

[wryun]

I was imagining option 1 (i.e. how it would work currently - we could nest bundles right now, after all... just no nice way to look up objects inside the bundles once they're resolved). In practice, I don't think the 'concurrency' loss will be a big problem, and it makes the system as a whole easier to reason about/visualise... much like the state layer does? Actually (more thought bubbles), one could probably replace that layer entirely with a 'state' smith pseudo-plugin (templater?) that generated a bundle inside the bundle (ok, ok, I'll stop, but it would be cool for people to decompose only one part of their structure...).

I was also thinking it might make the autowiring functions look nicer and make them easier to write for third parties, but probably not (could make them less flexible - need to think more).

Anyway, this and the kube object validation occured to me on on the train and missed my stop, so I had to comment :)

[wryun]

Oh damn, now I keep thinking... one could actually get a long way with a setup like:

• ostache/json-e template support as a smith resource (i.e. object, plugin OR template) to replace autowiring functions (templates can be registered as SmithTemplate CRDs). These templates would generate a single resource like plugins, but could generate a bundle of resources.
• allowing one to specify in the template what input parameters you require from the platform (cf rps-user-cloudformation) and your parameter schema
• these platform input parameters can come from any of 3 config maps (one for Smith, one for namespace, one for state), for different kinds of config (environment/region level, group level, service level); immediate fail if they don't exist. Could actually be even simpler than specifying which map by just doing them as overrides.

Feel free to delete this comment that is now super-unrelated to this issue. I know, I know, you want Smith to be simple/low-level.