Kptfile pipelines should support mount and network flags

[uv-Ic]

Describe your problem

I'm trying to use kpt pipeline with render-helm-chart function as mutator. In order to use local or remote chart we need to pass one of the following flags to docker which the Kptfile doesn't support:

• mount
• network

(In some cases the as-current-user flag is required as well.)

Current mitigation is to use exec mutator and run a script with the required flags, for example: snippet from kptfile

pipeline:
  mutators:
    - exec: ./render_command.sh
  validators:
    - image: gcr.io/kpt-fn/kubeval:v0.1

render_command.sh

#!/bin/bash
kpt  fn eval  \
  --image gcr.io/kpt-fn/render-helm-chart:unstable \
  --mount type=bind,src=$(pwd),dst=/tmp/charts \
  --as-current-user \
  --truncate-output=false \
  --results-dir /tmp/result \
  -- name=spanner-chart releaseName=test

It would be useful if we can pass these flags in the Kptfile like that:

pipeline:
  mutators:
    - image: gcr.io/kpt-fn/render-helm-chart:unstable
      mount: 
         type: bind
         src: .
         dst: /tmp/charts
      as-current-user: true
      configMap:
         name: spanner-chart
         releaseName: test

[droot]

Thanks for sharing the use-case details. I must say that's a very clever use of exec mode.

Typically, we think of fn render as an operation that will be performed whenever there are changes to package manifests. It's expected that package manifests will be generated on demand (first time with default values.yaml or when helm chart's version changes) instead frequently. So on-demand generation, it is recommended to use fn eval that supports network and storage.

Regarding the enhancements requests, we are open to support network access in fn render and it has been in our backlog for some time. However, there are concerns related to portability of a package in supporting storage in fn render.

[michaelvl]

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

[johnbelamaric]

@michaelvl thanks, that declarative version is much better, it's inline with some of what I was discussing in #3847

@tliron FYI with regard to the Nephio Helm support discussion.

[iuliancristea]

@droot @johnbelamaric are there any further plans here? I think that a solution to this would probably solve the problem of being able to fetch values dynamically from any remote data source as well.