Skip to content
This repository has been archived by the owner on Nov 1, 2022. It is now read-only.

Expose post-renderer as part of a HelmRelease install #365

Closed
coopernetes opened this issue Apr 8, 2020 · 5 comments
Closed

Expose post-renderer as part of a HelmRelease install #365

coopernetes opened this issue Apr 8, 2020 · 5 comments
Labels
blocked needs validation In need of validation before further action enhancement New feature or request

Comments

@coopernetes
Copy link

coopernetes commented Apr 8, 2020

Describe the feature
The post renderer feature was introduced in Helm 3.1.0 and allows for some really powerful chaining of tools together. For example, one can install a Helm chart and pipe the output to kustomize to apply a label transformer or add a secret/configMap generator.

It would be awesome if the helm-operator could accept an arbitrary command that can be executed as post-renderer by the operator after Helm renders out templates from a chart.

What would the new user story look like?
A custom annotation as an experimental feature?
An explicit field on the HelmRelease custom resource?

apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
  name: rabbit
  namespace: default
  annotations:
    fluxcd.io/helm-post-renderer: "./path/to/executable"
spec:
  postRender: ./path/to/some/executable
  chart:
    name: rabbitmq
    ...
  values:
    replicas: 1
    ...

Expected behavior
Either in the helm-operator image or through a custom image, allow an arbitrary string to be passed to the --post-renderer argument during the Helm install/upgrade step of the HelmRelease resource. Whitelist executables so only trusted binaries are allowed (such as kustomize) or allow users to use their own helm-operator image with their own executables.

@coopernetes coopernetes added blocked needs validation In need of validation before further action enhancement New feature or request labels Apr 8, 2020
@kferrone
Copy link

kferrone commented Apr 9, 2020

I was planning on suggesting this same feature. My vote is for post renderer option to use a custom image defined through a simplified job template. Then no change to Fluxcd/helm-operator is needed and we would simply define an arbitrary job with whatever image. Then Fluxcd/helm-operator would implement it's own post-render which runs the job described in the HelmRelease postRenderer. With our own custom images/jobs it would be very easy to experiment and do very custom things without having to redeploy or alter helm-operator in any way.

I was imagining something like:

apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
  name: rabbit
  namespace: default
spec:
  postRender: 
    image: my-custom/kustomize:latest
    cmd: ./patch.sh
    ... # the rest of the job template like volumes and env vars
  chart:
    name: rabbitmq
    ...
  values:
    replicas: 1
    ...

@RichiCoder1
Copy link

RichiCoder1 commented Apr 20, 2020

Yes please! This would be amazing and simplify some chart scenarios.

@clayrisser
Copy link

Please support this.

@RichiCoder1
Copy link

RichiCoder1 commented Oct 2, 2020

@codejamninja This project is now in maintenance mode, I created a new issue in the new project: fluxcd/helm-controller#104

@kingdonb
Copy link
Member

kingdonb commented Sep 2, 2022

Sorry if your issue remains unresolved. The Helm Operator is in maintenance mode, we recommend everybody upgrades to Flux v2 and Helm Controller.

A new release of Helm Operator is out this week, 1.4.4.

We will continue to support Helm Operator in maintenance mode for an indefinite period of time, and eventually archive this repository.

Please be aware that Flux v2 has a vibrant and active developer community who are actively working through minor releases and delivering new features on the way to General Availability for Flux v2.

In the mean time, this repo will still be monitored, but support is basically limited to migration issues only. I will have to close many issues today without reading them all in detail because of time constraints. If your issue is very important, you are welcome to reopen it, but due to staleness of all issues at this point a new report is more likely to be in order. Please open another issue if you have unresolved problems that prevent your migration in the appropriate Flux v2 repo.

Helm Operator releases will continue as possible for a limited time, as a courtesy for those who still cannot migrate yet, but these are strongly not recommended for ongoing production use as our strict adherence to semver backward compatibility guarantees limit many dependencies and we can only upgrade them so far without breaking compatibility. So there are likely known CVEs that cannot be resolved.

We recommend upgrading to Flux v2 which is actively maintained ASAP.

I am going to go ahead and close every issue at once today,
Thanks for participating in Helm Operator and Flux! 💚 💙

@kingdonb kingdonb closed this as completed Sep 2, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
blocked needs validation In need of validation before further action enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants