Adds kadet_params for compile time parameter injection into kadet modules

[sebradloff]

Adds kadet_params as a way to create compile time parameters for kadet modules. This should enable a reusable plugin like system within a single target, that shows the contract cleary through injection rather than relying on the 'parameters' concept in inventory.

The compile process currently works in a blocking sequential manner. Only targets are multi threaded. This enables a the concept of "post processing" or "overlays" as mentioned in #527 and #365.

Proposed Changes

• 'kadet_params' as attribute for kadet input type

[uberspot]

Hey @sebradloff thanks for the PR :)
Could you also add a couple sentences in the docs on how/why people would use this? Maybe in docs/compile.md(?).

[ramaro]

This should enable a reusable plugin like system within a single target, that shows the contract clearly through injection rather than relying on the 'parameters' concept in inventory.

Hey @sebradloff thanks for that. I'm not sure I understand this completely. I'm a bit confused because kadet_params is set in the inventory and missing the point. Can you elaborate with an example?

[sebradloff]

@ramaro yea I elaborated a bit in the docs that @uberspot requested. The idea is that sometimes there is a need for "post processing" or "layering" that can't be controlled in just one compile block. For instance, using the helm input type, I would like template manifests for a helm chart but maybe there's no parameter for something need to change or add to kubernetes resources. Instead of modifying the helm chart and now needing to be responsible for a custom helm chart, we can write a kadet module that takes parameters kadet_params and make the necessary changes there.

A common issue I've run into, is that some helm charts do not include the namespace for which you would like to deploy resources during templating and leave that up to deploy time. With that in mind, I would like to iterate over those manifests and add the namespace. I could do this without needing kadet_params but I would need to 1) setup an implicit contract with parameters that kadet reads in and 2) can only run the module once and would need to ensure it is the last compile block to run in order to transform all the necessary manifests. With kadet_params I can clearly specify the module to run and inject arguments for the post processing. This makes the module usage clear and the contract becomes explicit rather than implicit.

[sebradloff]

We could also use the example in the kadet proposal. Imagine that you wanted to reuse that module to create the same kubernetes objects for multiple classes or components in the same target. The only way to specify that right now, would be to modify the python code of the kadet module. With kadet_params you could inject the parameters instead of having to pull them from the kadet inventory.