add support for custom_labels

[ltagliamonte-dd]

Would be nice if could be possible to specify additional labels in values.yaml for all components (I'm just interested in the client atm).
We use a set of internal labels for monitoring and alerting.

[ishustava]

Hey @ltagliamonte-dd @DevAndrewGeorge

I just noticed that Helm 3.1 now supports post-rendering. I think it's a pretty cool feature that allows you to essentially modify the Helm chart that fits your use-case and inject all kinds of information. I like it because it provides you with an escape hatch while still keeping all helm features we're using (e.g. helm hooks) in-tact. This way you don't need to depend on us to support something like that.

Here is an example of using it with Kustomize. You could pretty easily modify it to apply labels to all resources by using commonLabels.

It's a pretty new feature, and so it still might be pretty raw. I'm curious to hear what your thoughts are.

[ltagliamonte-dd]

Unfortunately my flux gitops pipeline doesn't support post rendering:
fluxcd/helm-operator#365
Would be a big deal to add native support?

[DevAndrewGeorge]

It's certainly a cool feature, @ishustava, and I got it to work in my hobby environment with a bit of hacking. However, it required an entirely new step in my deployment pipeline as I'm using Helmfile and --post-renderer is only called if changes are detected, creating a chicken and egg problem.

At a high level, I can see the advantage of using kustomize + post-render, but I personally see their usefulness in advanced customization in specs, such as overriding service accounts, modifying environment variables, etc. I think it's good hygiene for a Helm chart provider to empower end users to have full control over common metadata details that are standard in k8s.

[lkysow]

I think it's good hygiene for a Helm chart provider to empower end users to have full control over common metadata details that are standard in k8s.

For sure. Thanks for your feedback on post-renderer. It's always a balance of what options we expose to users and what options we ask users to go their own way on because there are so many possible configurations that can be exposed.

In the case of labels, exposing this via its own value makes sense.

[korjek]

What's the status of this request? We also need custom labels support.

PR is opened more than 6 months ago. Could we have it merged?

[korjek]

is this thread dead and no plans to add custom labels support?

[david-yu]

@korjek We are aware of asks around custom label support and have incrementally been adding support across various components. Here is one that recently merged: #612

Could you describe what else might be potentially missing? We are considering adding a global custom label option but that may be more work to plumb through.

[korjek]

@david-yu awesome! thank you!

P.S. I'm not the author of this ticket, but it looks like this ticket can be closed now.