-
Notifications
You must be signed in to change notification settings - Fork 7.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why Helm release name is a DNS label with max length of 53 characters? #6006
Comments
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. Lines 49 to 54 in 02ad2b1
|
@bacongobbler shouldn't helm be up to 63 characters as weel? Because when a chart is create it limits to 63 characters in the |
See the comment in the code linked above.
|
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? |
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: |
@hickeyma thanks, I was checking the kubernetes repository and I found that. |
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:
|
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 |
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 SummaryServices 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 TestsIn 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 The tests operate by attempting to create a list of resources, each with a metadata:name field that is 231 characters. Test ResultsService was unable to be created and the following error message was given.
The other three resources tested (list below) were created successfully! Resources tested
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. 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? |
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. |
Helm documentation states the following:
-1) (k8s) metadata.name is restricted to a maximum length of 63 characters because of limitations to the DNS system
-2) For that reasons, release names are (DNS labels that are) limited to 53 characters
Statement 1) is not correct.
k8s does not impose a max length of 63 characters on resource names.
The actual max length for a resource name is 253 characters.
The k8s resource name is in fact a DNS subdomain (that can be made of one or more DNS labels).
Should we make the release name a DNS subdomain?
The text was updated successfully, but these errors were encountered: