Long ago Kubernetes service names were restricted to 53 characters. More recent versions of Kubernetes allow longer service names, though there was a time that some users were using the older version of Kubernetes so we couldn't relax the constraint. We can probably relax that constraint now.

Which parts would have to be updated to relax the constrain?

Not sure if much has changed since #1560, but looks like that bumped it last time.

Here is where it resides today.

@bacongobbler shouldn't helm be up to 63 characters as weel?

Because when a chart is create it limits to 63 characters in the _helpers.tpl file.

See the comment in the code linked above.

// As of Kubernetes 1.4, the max limit on a name is 63 chars. We reserve 10 for
// charts to add data. Effectively, that gives us 53 chars.
// See #1528

We upgraded to Helm3 but now helm render fails with "release name exceeds max length of 53" error. What is the resolution here? Is Helm planning to increase the character limit?

It's not perfect, but we run our release names through a little bash function ahead of time:

function normalizeHelmReleaseName {
    # See https://github.com/helm/helm/issues/6006#issuecomment-553184466
    if [ ${#1} -gt 53 ]; then
        printf "%s-%s" $(echo -n $1 | cut -c -44) $(echo -n $1 | sha256sum | cut -c -8)
    else
        echo -n $1
    fi
}

@vaibhav-si we'd welcome PRs to increase the character limit to whatever's reasonable in more recent Kubernetes versions. It's open source! Feel free to contribute.

@bacongobbler I would love to contribute, is there a documented process for contributing? How does the build system work?

https://helm.sh/docs/community/developers/

https://github.com/helm/helm/blob/master/CONTRIBUTING.md

See the comment in the code linked above.

// As of Kubernetes 1.4, the max limit on a name is 63 chars. We reserve 10 for
// charts to add data. Effectively, that gives us 53 chars.
// See #1528

What is the rationale behind choosing 53 chars for release_name and 10 for chart data

With recent versions of kubernetes supporting 253 characters what should be this ratio now?

See the comment in the code linked above.

// As of Kubernetes 1.4, the max limit on a name is 63 chars. We reserve 10 for
// charts to add data. Effectively, that gives us 53 chars.
// See #1528

What is the rationale behind choosing 53 chars for release_name and 10 for chart data

With recent versions of kubernetes supporting 253 characters what should be this ratio now?

@bacongobbler could you answer this?

I think I already answered that question earlier in the thread. #6006 (comment)

hi @bacongobbler I'd love to fix that as my first PR here. The goal is change to 243 and keep 10 for chart data,right ?

Just to be sure, I would advise doing some testing (and some digging in kubernetes/kubernetes to make sure that assumption of 253 characters for a service name still holds true today). But assuming that works, then yes, bumping the release name maximum character length to 243 characters should be fine.

@renatosuero It seems to be 253 alright: https://kubernetes.io/docs/concepts/overview/working-with-objects/names

You would need to take into account that a release is stored as a Secret/ConfigMap in the cluster with the following nomenclature for its name: sh.helm.release.v1.<release_name>.v1. This means then it would be 253 -22 (prefix postfix of name) = 231 characters

@hickeyma thanks, I was checking the kubernetes repository and I found that.
https://github.com/kubernetes/kubernetes/blob/cfc845be63e88451779d209ecebbed81af54cdfa/staging/src/k8s.io/apimachinery/pkg/labels/selector_test.go#L321

https://github.com/kubernetes/kubernetes/blob/aadaa5d6a917fcb354bce80a0bd1830c95cfbcc3/staging/src/k8s.io/apimachinery/pkg/util/validation/validation.go#L202

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.

Pull Request to fix this, is still open. Would really be great to move away from this no longer existing limitation.

We’ve been waiting on action from the author on writing up some tests since last month, so if someone wants to go and try to move the work ahead please feel free. But yes, once this is squared away we can remove this limitation.

Sorry I'm a bit busy the last weeks :( I need first see how k8s to do the tests, so I don't know when I'd finish it :(

@bacongobbler I can work on the k8s infrastructure tests assuming @renatosuero is still busy.

thank you very much @Stolarskis

Hi guys! In order to test this, my plan was to use terratest to spin up a helm chart that creates a variety resources using a release name that is 231 characters long. Do you think this would adequately test this change? Or does helm already have tests similar to this I can base mine off of?

Couple other questions:

• Where would we store terratests in the helm codebase? Do we even want to store tests like this in the main helm repo?
• In the helm docs it says that for helm 3.4.x the oldest version of k8s we support is 1.16.x. Is this the oldest version of k8s you want this change to be tested against?

I would suggest using the pre-existing unit tests to validate against Kubernetes' validation suite. Specifically have a look at pkg/kube/client_test.go on how Helm validates using the fakeHTTPClient from k8s.io/client-go/rest/fake. If that isn't possible, there is also the acceptance-testing project.

pkg/action/install_test.go might be another place well worth looking into.

Hey guys! Sorry for the delay, holidays are super busy. Heres what I found!

Findings Summary

Services have a max of 63 characters for the name attribute. Changing the max release name value will not work if the release name is included in the service name.

To verify this, I wrote some tests you can view here!

Kubernetes Live Tests

In kube/client_test.go, I found some live tests that run requests against a live cluster. Using those tests as an example I created a couple tests that attempt to create a few resources on a local cluster (I used minikube). The version of which is below.

Client Version: v1.19.3
Server Version: v1.19.4

The tests operate by attempting to create a list of resources, each with a metadata:name field that is 231 characters.

Test Results

Service was unable to be created and the following error message was given.

--- FAIL: TestRealMaxResourceName (0.02s) client_test.go:355: Service "xvl..." is invalid: metadata.name: Invalid value: "xvl...": must be no more than 63 characters

The other three resources tested (list below) were created successfully!

Resources tested

• Deployment
• Service
• Config Map
• Secret

Let me know if any other info is needed! Happy New Year!

Could we make the max length of the release name a setting property to let user decide to set this value; If not set, default is 53.

I think this will meet the user's needs as well as keeping the backward compatibility.

How is a user supposed to know what they should set the release name length? Keep in mind that many users do not (or should not) understand the intervals of the chart, so you should not run with the assumption that the user immediately knows what the correct release name length may be.

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.

Any solution for that ?

could someone reopen this issue or provide the solution?

This issue is especially annoying, if you try to do ReviewOps on a Helm Chart via ArgoCD using an ApplicationSet.
... the max Name length for an Application is 253chars, following the K8s max name length.
That name will be used for the release, too -> Helm dies.

Yes, we can overwrite the releaseName on generation, but I'd prefer not to have to, cause this cuts out a couple of dynamic naming options.

Hey folks, it's 2024 and helm release names are still limited to 53 characters. Can this be revisited?
I find it pretty easy to hit the limit and unfortunately this tends to encourage using short non descriptive names, in addition to making tooling more complicated around it.

Kubernetes identifiers (e.g. name, label key) have restrictions.

When the Chart uses the Release name in some identifier, then a user of that Chart, by using a long enough release name, could cause that identifier to violate some restriction. That would likely be a surprise to the user, because only the Chart maintainers would know where the Release name is used. I think that helm maintainers were doing their best to shield Chart users from this problem.

If helm removes this restriction, the maintainers of each Chart will be responsible for shielding their users from this problem.

That seems like a reasonable responsibility for Chart maintainers to have. However, the responsibility would be new, and they would need sufficient time to prepare.

Helm could help Chart maintainers cope with the new responsibility by documenting some best practices of naming, i.e. when to use a Release name in identifiers, and how to transform it to conform to restrictions.