Filing this so we can revisit.
@satnam6502
Service names (and apparently Namespace names in the client, but not the server) are restricted to DNS 952 labels (24 characters). Most other API Objects have names that are DNS 1123 subdomains (much longer).
In doing tests it is useful to generate random names, and this is a bit annoying for services.
Can we expand service names?
- DNS 1035 labels (longer)
- DNS 1035 subdomains (longer and allow dots)
- DNS 1123 labels (longer, allow leading digit)
- DNS 1123 subdomains (longer, allow leading digit and dots)
(4) would be most consistent with other objects.
If we do (2) or (4) we need to convert dots to underscores in env-var names, which could cause a collision (e.g. foo-bar and foo.bar). Maybe double underscore for dots?
If we do (3) or (4) we need to handle leading digits in env-vars. Maybe a prefixed underscore?
(1) seems least controversial, but is still different than everything else.
Filing this so we can revisit.
@satnam6502
Service names (and apparently Namespace names in the client, but not the server) are restricted to DNS 952 labels (24 characters). Most other API Objects have names that are DNS 1123 subdomains (much longer).
In doing tests it is useful to generate random names, and this is a bit annoying for services.
Can we expand service names?
(4) would be most consistent with other objects.
If we do (2) or (4) we need to convert dots to underscores in env-var names, which could cause a collision (e.g. foo-bar and foo.bar). Maybe double underscore for dots?
If we do (3) or (4) we need to handle leading digits in env-vars. Maybe a prefixed underscore?
(1) seems least controversial, but is still different than everything else.