HIP: Validate length of names and labels rather than relying on truncation

hips/hip-9999.md

@@ -0,0 +1,83 @@
+---
+hip: 9999
+title: "Automatically validate the length of names and labels instead of relying on truncation"
+authors: [ "@jarebudev" ]
+created: "2025-10-19"
+type: "feature"
+status: "draft"
+---
+
+## Abstract
+
+To prevent errors arising from names and labels being longer than 63 characters, chart templates by convention contain logic to truncate and trim values that are longer than 63 characters before applying these to Kubernetes
+
+This proposal is to make changes to Helm so that the length of names and labels are validated by Helm before applying to Kubernetes, failing if any name is greater than 63 characters.
+
+## Motivation
+
+Currently, the approach for handling too long name values for names is to 'truncate and trim' these if they are greater than 63 characters.
+
+Helm encourages this convention by creating helper methods in charts created using the `helm create` command.
+
+These charts contain this pattern within the generated `templates/_helpers.tpl`, which is generated by `pkg/chart/v2/util/create.go`.
+
+This requires chart developers to ensure that they are applying this throughout their templates.
+
+Apart from additional boilerplate code that is added to charts, this approach has a drawback as it attempts to shield chart users from their choices of invalid names which exceed the naming limit.
+
+By changing Helm so that it checks any resource name or label value to be less than 63 characters, it forces the chart user to reconsider their naming of charts and releases to fit their Kubernetes deployment strategy.
+
+
+
+## Rationale
+
+Ensuring that Kubernetes workloads are deployed with consistent and meaningful names is a large part of Kubernetes deployment engineering.
+
+Most resources in Kubernetes have a 253 character limit.  The 63 character limit applies to pods, services, labels, and CronJobs.  
+
+Blanket truncating to 63 characters, as Helm currently encourages, ensures that names supplied to a template will fit within Kubernetes naming limits and not lead to a Helm deployment failure.
+
+Truncation however is in effect an attempt to avoid a configuration error by the chart user as it's hiding the error, rather than making the chart user ensure that their configuration does not violate Kubernetes naming restrictions.
+
+Truncation can also lead to naming collisions when deploying multiple times to the same namespace.
+
+Instead of truncating, Helm should fail before applying if the template resource name or labels, forcing chart users to adjust their resource names to suit.
+
+By reducing the need for truncation and trimming logic in chart templates, this will also lead to a small reduction of bloat in charts, enabling chart users and developers to focus on the relevant chart logic.
+
+
+## Specification
+
+- Resource names or label values fail template validation if a value provided is greater than 63 characters.
+- `pkg/chart/v2/util/create.go` to be changed so that `templates/_helpers.tpl` no longer contains the logic to truncate and trim names to 63 characters.
+
+## Backwards compatibility
+
+Charts that already truncate names and labels to 63 characters will not be impacted by this change (as they are already ensuring the name/label is not more than 63 characters long by truncating).
+
+## Security implications
+
+None
+
+## How to teach this
+
+Via documentation
+
+## Reference implementation
+
+TBC
+
+## Rejected ideas
+
+Automatically truncating and trimming names and labels. 
+
+Adding a new function for chart developers to use that will fail the validation of a template if a value supplied to be used for the name is greater than a chart developer specified length.  This would be useful for `Deployment`s which names are recommended to be less than or equal to 47 characters as greater than this has implications for the names of Pods generated by the Deployments.  This should be proposed and discussed in another H4HIP.
+
+
+## Open issues
+
+N/A
+
+## References
+
+- [kubernetes dns-subdomain-names](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-label-names)