Description
Describe the bug
We've recently update to v0.106.1 in our distro of the collector, and we've found that some of the names for components end up being too long for the new validation logic (#10674).
For example, we have this as the component name: Linux-Messages-File_01J49HCH3SWFXRVASWFZFRT3J2__processor0__logs
This give this error message:
cannot unmarshal the configuration: decoding failed due to the following error(s): error decoding 'processors': in "Linux-Messages-File_01J49HCH3SWFXRVASWFZFRT3J2__processor0__logs" id: invalid character(s) in name "Linux-Messages-File_01J49HCH3SWFXRVASWFZFRT3J2__processor0__logs" error decoding 'service.pipelines[logs/Linux-Messages-File_01J49HCH3SWFXRVASWFZFRT3J2__QRadar-HTTP-1].processors[3]': in "Linux-Messages-File_01J49HCH3SWFXRVASWFZFRT3J2__processor0__logs" id: invalid character(s) in name "Linux-Messages-File_01J49HCH3SWFXRVASWFZFRT3J2__processor0__logs"
For context; In BindPlane, we generate the names for components, which makes them verbose like this, and helps us to understand where the component is generated from (in terms of our own schema). So we'd really like to keep the longer component names, but it looks like the new validation has limited it to 63 characters.
I'm looking to understand why we need a character limit on the component name, and if it's possible to raise or remove this limit.
Also, related, the error message is a bit confusing. It claims invalid character(s) in name - but actually every character in the name is valid, it's just the length that's the problem; I think the length check should be separate from the regex, so we can give a proper error message here.
What version did you use?
v0.106.1