Consider "nested" bundle support

atlassian / smith

Smith is a Kubernetes workflow engine / resource manager

Apache License 2.0

285 stars 24 forks source link

Consider "nested" bundle support #250

Open wryun opened 6 years ago

wryun commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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.