Support Helm PostRender Functionality

[RichiCoder1]

Describe the feature

It might be a little harder given the toolkit's new structure, but it'd be great to see support for Helm's Post Render functionality.

This allows for customization of out-of-the box charts without having to manually untar and manipulate the base chart.

Alternatives

Probably an advanced feature, but being able to chain Helm and Kustomize controllers would be another way to attack this.

[kferrone]

Maybe just allow a Flux specific post render. I suggested to Crossplane to include a simple patch method to their Helm controller, they agreed. I suggested to implement a simple post render json patch. Then implementation would look just like how kustomize does patches, something like:

patches:
- patch: |-
    - op: replace
      path: /some/existing/path
      value: new value
  target:
    kind: MyKind
    labelSelector: "env=dev"

Then you don't need to deal with the chaos of all the different ways a post render may look and this basically covers most possible use cases.

[hiddeco]

This is a great feature request and slipped through the cracks while I collected "highly upvoted issues" from the Helm Operator to determine the feature set for the helm-controller. It had already resurfaced in my mind due to discussions with @scottrigby, but had not been recorded in an issue yet, so thank you for doing just that. 🌻

Your proposal @kferrone, would serve use-cases where you want to apply a simple patch to the manifests rendered by Helm very well. This may be sufficient to most users, but due to the fact that the feature in Helm is still relatively unknown[1], there (still) is a lack of real world (non-declarative) examples to confirm this.

However, if this turns out to be limiting, we will eventually hear about it from our users and can then think about extending the support for other post-renderers (one way that has crossed my mind is by utilizing jobs with user defined images, but note that keeping track of jobs is not a light introduction), as long as we design the API properly.

[seaneagan]

Perhaps we could use KRM config functions for this, which would provide robust capabilities without any need to support arbitrary renderer binaries running inside the helm-controller (container images instead). See also the related kustomize functionality. Whatever support we include there for configuring the function runtime (e.g. network access) we'd want to probably allow the same here. As far as where to source the function definitions from:

1. Via a path within a GitRepository or Bucket:

spec:
  functions:
    path: manifests/functions
    sourceRef:
      kind: GitRepository
      name: ...

The function runtime has some logic to determine the order of functions based on the directory layout etc.
2. A list of configmaps/secrets keys
3. A directory within the chart
4. Directly from the chart output

1. and 2. seems nice for being able to store your function configs alongside your HelmReleases. However with 1. I'm not sure how to reference a source from the manifests within that source (HelmRelease in this case). 2. solves this, but does require applying the configmaps/secrets to the cluster, but that's not a big deal. 3. and 4. require ownership of the chart to be able to make the updates which seems less useful.

[hiddeco]

@seaneagan I am afraid that using KRM config functions from within a Kubernetes Pod is not possible.

If you look at the diagram here there is an assumption that local containers can be spawned (as possible in e.g. a CI pipeline), but a Pod in Kubernetes does not have access the Controller Runtime Interface (which is a great thing), and can thus not spawn any containers.

In addition to this technical limitation, I think that diverging from the functionality and the PostRenderer interface as introduced by Helm creates a xkcd#927 situation, and find the API proposal difficult to understand (which is a sign that it may be even harder to understand for users coming from a Helm background).

[ghost]

This implementation would be amazing for my implementations since I'm currently forced to fork a lot of Helm charts used on production clusters by Flux.

[kdorosh]

@hiddeco any updates on this one / roadmap?

[hiddeco]

No updates on this from my side yet, but I welcome PRs with an enhancement as described in your comment.

[hiddeco]

Solved in #202.