Open howardjohn opened 3 years ago
Poor mans solution as a makefile:
generate: ## re-generate all manifests
@mkdir -p $$HOME/.khelm
cd manifests; find -name khelm.yaml | xargs -I{} $(KPT) fn eval \
--image mgoltzsche/khelm:v2 --network --mount "type=bind,src=$$HOME/.khelm,dst=/helm,rw=true" --as-current-user \
--fn-config {}
kpt fn render manifests
We're unlikely to allow mounts. That won't work with packages fetched via the package orchestrator.
We're considering how to pass arbitrary files as input. #3118
Network access may still be necessary and possible.
An alternative take on rendering Helm charts in declarative pipelines can be found here: https://github.com/michaelvl/krm-functions/blob/main/docs/render-helm-chart.md
Describe your problem
pipelines
used bykpt fn render
should allow mounts and network access.There is some discussion in https://kpt.dev/book/04-using-functions/02-imperative-function-execution?id=privileged-execution.
I would argue this degrades the user experience dramatically. Consider an extremely common use case - rendering helm charts. I want to define some function config like:
And then have the chart rendered and stored as a local yaml file (which can then be further mutated by pipeline).
Because of restrictions on network access (and mount is useful for cache and local helm charts), this is impossible.
That leaves a few choices:
kpt fn eval
. If I am using kpt, I of course want a declarative setup, so clearly I am going to need to add some tooling here to do this... and now I have invented a poor version ofkpt fn render
...IMO these alternatives show that it would be a huge improvement to allow this access. If it requires
kpt fn render --allow-unsafe
or whatever, no problem.. but right nowrender
is hindered enough suchRelated discussions: