Excluding shorten UID from the release name

[Jinchul81]

Feature Request

Is your feature request related to a problem? Please describe.
I am trying to migrate Helm chart management from Helm-Tiller(a.k.a. helm.sh) to Helm-operator. There is an issue that unexpected shorten UID is always embedded into the release name. You know MSA consists of diverse applications. Thus, there are dependencies among them. Before I am using Helm-operator, referer's naming rule should be clear because the name is always under my control. By the way, the shorten UID makes an unknown name.

Would you please explain why the shorten UID generation was introduced in this code?
This should ensure uniqueness, so I guess you might not be want to any conflict issue from duplicate names. I know that it can be happened by mistake, especially human-being. However, Kubernetes system does not accept the mistake and throws an error. Additionally, Helm-Tiller does not add the UID into the release name.

I would like to raise the drawbacks on the issue.

1. Easily encounter to the length limitation of name or label. The shorten UID occupies 26 characters. It means the original name could be shortened or truncated. In my case, longer names are usually adopted for the meaningful naming convention. I prefer to more intuitive or full name rather than abbreviated one.
2. The release name propagates the relevant naming rules such as service, hostname and so on.
   Here is a simple example to explain what I meant above. The length of the hostname of the first is 120. I think the hostname seems not to be readable compared with the second.
   myapp-4ryig7jybm6k4gkh0732sr8ar-coordinator-0.myapp-4ryig7jybm6k4gkh0732sr8ar-coordinator.mynamespace.svc.cluster.local
myapp-coordinator-0.myapp-coordinator.mynamespace.svc.cluster.local

Describe the solution you'd like
Here are some of my attempts to solve this issue:

1. (preferred) Is there any parameter or flag(e.g. env. variable) to ignore the shorten UID generation for helm-operator binary in the base Docker image? Unfortunately, I have realized that there was no parameter except for watches-file when I checked the file entrypoint in the base image. Would you mind if I propose the feature will be implemented? I am supposed that you might have a better idea or approach not to generate the shorten UID.

2. Here is an alternative way to retrieve a release name using by my given name. There is no change on your code compared with the above attempt. An application(e.g. App2) needs to refer to a service of a dependent application(e.g. App1). I assume that App1 and App2 should be unique names in namespace or cluster. I can find a release name using the App1 as a prefix and then I can rely on the name. By the way, this approach should require additional cost and complexity such as finding names.

3. Please suggest your guidance if you have.

[joelanford]

@Jinchul81 we have an open issue to support predictable/customizable release names already. See #1094.

We've been making some improvements that should make it easier to support this, but we haven't quite gotten to this yet.

Since there's already discussion taking place in #1094, I'm going to close this as a duplicate.