According to the Kubernetes docs, some resource names have a max length of 63 characters while others have a max length of 253 characters. I'm trying to figure out which objects have the 63 character length right now. It appears that Containers, Namespaces, Service Ports, Volumes, CSI Drivers and EndpointPorts are all limited to 63 character names.

Charts will occasionally create namespaces. How should this be handled?

ping.

Sorry busy days. I checked in the kubernetes code, I found label and job has the limitation. Regarding how to should this be handled, maybe we could check the resource and apply the correct limit, what do you think @mattfarina ?

The fixed max length releaseName may face a special case:

secret name max length limitation is 253.

the release name length is 231, the secret name length is 253 equally, and then upgrade the release to version 10, the computed secret name length could be 254, which is not satisfied with kubernetes object name spec.

@liuming-dev, I didn't get your point. the 231 value was calculated here. Could you explain your point

@liuming-dev, I didn't get your point. the 231 value was calculated here. Could you explain your point

For example:
release name is aaaaaaaa…(231 characters of a), and the latest version is 9, that means sh.helm.release.v1.aaaaaaaa….v9, length up to 253 already. when upgrade the release to version10, sh.helm.release.v1.aaaaaaaa….v10, length up to 254 and has exceeded the maximum limit.

Another point need to be noticed, release name is used in release secret label, that means its length should not be more than 63 characters.

thanks @liuming-dev I got your point now. what do you suggest to fix that?

ping

@renatosuero This potential issue here is that not all Kubernetes resources are max character length. Some charts name resources using the release name. Have you investigated all Kubernetes resource/object name sizes?

@hickeyma I'll double check again, but If I'm not wrong the labels are the only one which still have 63 chars

@renatosuero as a suggestion, you could write unit tests to generate kubernetes resources using releaseNameMaxLen to verify. That would help ensure future updates won't accidentally break something as well.

Have a look at the kubernetes test infrastructure for ideas.

Any updated?

closing as inactive. If someone wants to carry on the work and address some of the other maintainer's comments, feel free.

@bacongobbler
I don't think it be necessary for helm to make the package totally usable by k8s.
'cause k8s use helm, not versa.
It is the user's duty to make sure their package usable by k8s, or elsewhere.
I really think we should only print a warn message at console when people wanna make such helm, but no hard liminitions.