In T176027#3612209, @bd808 wrote:

According to the Kubernetes source code, a Namespace must comply with the definition of a DNS Label:

// DNS_LABEL:  This is a string, no more than 63 characters long, that conforms
//     to the definition of a "label" in RFCs 1035 and 1123. This is captured
//     by the following regex:
//         [a-z0-9]([-a-z0-9]*[a-z0-9])?

From RFC 1035:

The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less.

Our current rules for a tool name are not the same which is both surprising and unfortunate. We currently use rules based on an interpretation of the recommendations made by useradd(8) for tool names as coded in this regular expression: ^[a-z][a-z0-9_-]{0,31}$

There are two general ways I can see to "fix" this problem going forward:

• Change our tool -> namespace mapping from the current identity mapping to some repeatable transformation (hash) that is encoded in a way that matches the RFC 1035 restrictions. This has a disadvantage of making it more difficult to reverse from a Kubernetes namespace to the owning tool.
• Change the tool name restrictions to match the intersection of the useradd(8) and RFC 1035 restrictions. This would basically mean dropping _ as a valid character. This would not fix the problem currently being encountered by the wdq_checker tool, but it does seem to be the only tool that exists which has used the _ character.