Helm adds release name to dependent charts

[canuysal]

I have few dependencies like this

dependencies:
- name: some-chart
  version: "1.2.3"
  repository: "file://../some-chart"

And I install my chart like so

helm install my-chart .

However, it adds dependent charts my release name. so for example a pod deploys like this

my-chart-some-chart-server-0

If I only install the dependent chart on its own, for example helm install some-chart ../some-chart it deploys like this

some-chart-server-0

Is there a way to deploy dependent charts without adding release name as its intended?

helm version : 3

[mattfarina]

The short answer is no. Here is the context.

To understand why Helm does this it's helpful to know some of the priorities, tradeoffs, and scope.

First, Helm is a package manager. It's akin to apt, yum, and other package managers. It's not a tool to manage your environments like chef, puppet, or ansible. Those tools end up leveraging package managers like Helm. If you want a tool like those I would suggest looking at things like Helmfile, Flux, etc. If you look at these other tools you will see some very different styles used to manage what's in a cluster.

Second, Helm prioritized certain roles. Among those are those who operate applications in cluster and those who need to distribute applications for them to operate.

Third, there is a tradeoff to be made for the role of installing applications into a cluster between those who are Kuberentes insiders who know the platform and those who don't know it well. The role of application developer or application operator if often not someone who knows Kubernetes intimately well. So, Helm priorities making their experience very usable.

Fourth, Kubernetes is not only multi-tenant but also capable of installing the same application into the same workspace multiple times. And, some people do that. Helm must work within this scope because it has long been used within this scope.

With that in mind, let's say you have WordPress and it depends on MySQL. Now, someone goes to install it twice in a namespace. You have the MySQL with its own release name. How does each of those get a unique release name for each installation if it's not based on the top level one?

If someone wants to control the MySQL release name, in this example, they can install it separately and provide the location to the WordPress chart. This can be done manually or using an outside management tool. If someone wants to install the whole package together the MySQL component is tightly coupled to the WordPress installation for the sake of user experience.

If you have a suggestion on how to handle this situation more elegantly we are willing to listen. But, this is some of the context to how we got here.

[github-actions]

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.