Modifying chart resources after they has been rendered

[wclr]

I think it is quite often situation when there is chart with needed service and in general it does what it should, but template is not quite flexible to to make what is exactly needed in particular case. As I understand the only option is to download chart source modify template and use these new one.

I think it would be convenient in some cases just to have script/hook that could access and make minor modification to already final resources rendered from the template, just to avoid cloning and keeping/messing with excessive chart sources.

What do you think about it? What are the problems of such approach?

[thomastaylor312]

I can definitely see why someone would want to have this available. Others have floated ideas to allow you to set specific attributes of a k8s manifest with an install (can't find the issue for the life of me right now). The way you have proposed it here would be difficult because you are having something out of band modify a chart and I would worry about edge cases where we lose track of the "true" manifest needed

[wclr]

set specific attributes of a k8s manifest

You mean with cli args? But it is really not clear how to provide a correct "address" of the attribute.

we lose track of the "true" manifest needed

It is the responsibility of the user.

[thomastaylor312]

Yeah, it would be a cli flag where you pass something like spec.template.metadata.name=test.

As for things being the responsibility of the user, I still worry about giving too much rope for people to hang themselves with. Also, I feel like it defeats the purpose of having something manage the state of the manifest if things are modified outside of it. There could be too many situations where an upgrade could stomp on it. But I could very well be wrong about my thinking

[wclr]

spec.template.metadata.name=test

How would you identify the resource exactly which should be modified?

[thomastaylor312]

Oops, I forgot to put the resource name. It would be something like deployment.<name> at the beginning of that. But that is all loosely designed off of an idea I saw someone float once

[wclr]

How do you know what particular deployment if you have multiple in your chart? Esp multiple resources of the same time in one template file?

[bacongobbler]

I think we should close this as something out of helm's scope similar to #2243. I know that helm template generates the templated chart manifests which then users perform post-processing on their own. I think that is the right approach to stop us from writing a tool that is said to be turing complete.

If I'm wrong and there's still value in adding this feature and/or it's a relatively simple PR, please feel free to re-open! :)

[colinmorelli]

@bacongobbler generally I agree with you - but I think there are some cases where this does make sense. For example, I just used helm to install zookeeper. Everything that it sets up is fine, but the service is just a ClusterIP. In our development environment I’d like an internal load balancer setup so it can be accessed from outside the cluster. My options are, as far as I can tell:

• Edit the chart and submit a PR to support changing the service type
• Use helm template and give up helm’s management features
• Create another service on top of the helm managed one that exposes a load balancer

#2/3 both feel wrong for such a simple need. #1 discourages experimentation.

I could be missing something very simple though.

[wclr]

Maybe this is out helm scope but there is definitely a problem with the inflexibility of official heml charts templates, I've heard this multiple times from devOps.

Again I see those problems with current templates:

• Though mostly official charts fit standard needs, there may be cases where they don't and you have to go though clumsy procedure of cloning, just to change couple of minor things.

• The second problem is an agreement on the naming of the created resources which is .Release.Name $name, that is common for all official charts, and you can not agree on this, or you will have to clone everything. =)

• The third problem is composability for creating charts, there is actually quite limited with yaml and go templates.

For my own charts I use TypeScript, which allows:

• To have fully typesafe experience while creating charts configs (kubernetes API is really simple to type, and have multiple typed versions to ensure consistency).
• Have fully composable interfaces for creating resources/charts objects/helpers, whatever, allows easy modifications of ready-to-use charts resources by the end-user.
• Docs for API embedded in the code.
• Potentially use standard ready infrastructure for packages distribution (NPM).