The 24 character Service limit

[srcspider]

Can this be removed? It's really annoying limit.

Description of problem

If you type any service name that's more then 25 characters (and I assume other naming rules also apply) you will get something like the following error:

The Service "a-25characterslongstring" is invalid:metadata.name: invalid value 'a-25characterslongstring': must be a DNS 952 label (at most 24 characters, matching regex [a-z]([-a-z0-9]*[a-z0-9])?): e.g. "my-name"

RFC 952: https://tools.ietf.org/html/rfc952

So why is 24 characters long a problem? Let's say you have a cluster, and you have many projects on that cluster and you have many services per cluster and you also have different stages to development that also sit on said cluster. Ok so, given all that if you say have "project1" and two services "www" and "api" and you have a stage in development called "testing" you now have a service name that might look like this "project1-testing-www-svc" (25 characters, so illegal). I find it not being able to handle such a extremely simple name quite a bit troublesome.

I don't know where and how exactly RFC 952 applies to the service name (is this just for some future compatibility?), but as far as I'm concerned if I write "project1-testing-www-svc" then I'm writing it for myself and other developers; I'm not writing it for some network table. The network table can have it as "asdjasjkfghajks" for all I care.

Assuming RFC 952 compatibility here is relevant, can we have something like "metadata.alias" which would support at least 255 characters long names and just automatically generate a unique 24 character id. Any sort of getters would report the alias with the actual name in parenthesis, eg.

project1-testing-www-svc (qn37txumha6tfmm19gokei3w)

For me personally even something like just a little mark would be enough (eg. project1-testing-www-svc* or @project1-testing-www-svc). The real ID can be hidden under a flag 99% of the time.

[ghost]

Sorry for going a bit offtopic, but you might consider using namespaces to bypass the limit:
www.project1-testing.cluster.local
Here the service ist just called www and the namespace is project1-testing. This bypasses the limit and also allows for project/namespace related resource quotas. If you use the optional dns addon you can then use a database in your namespace by simply using db as the hostname, which will be resolved to the service db.project1-testing.cluster.local

[srcspider]

@maklemenz doesn't seem to work for me,

nano test.svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: www.verylongprojectname.testing
  labels:
    type: deleteme
spec:
  ports:
  - port: 1234
    targetPort: 1234
  selector:
    type: nothing

kubectl create -f test.svc.yaml

The Service "www.verylongprojectname.testing" is invalid:metadata.name: invalid value 'www.verylongprojectname.testing': must be a DNS 952 label (at most 24 characters, matching regex [a-z]([-a-z0-9]*[a-z0-9])?): e.g. "my-name"

If I'm doing something wrong let me know. Using google container engine for cluster.

[ghost]

@srcspider Try something more like this:

project1-testing-namespace.yml:

apiVersion: v1
kind: Namespace
metadata:
  name: project1-testing

project1-testing-www-svc.yml:

apiVersion: v1
kind: Service
metadata:
  name: www
  namespace: project1-testing
  labels:
    type: deleteme
spec:
  ports:
  - port: 1234
    targetPort: 1234
  selector:
    type: nothing

$ kubectl create -f project1-testing-namespace.yml
$ kubectl create -f project1-testing-www-svc.yml --namespace="project1-testing"

further reading:
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/admin/namespaces.md

the described lookup will only work if the dns addon is installed:
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/admin/dns.md

[srcspider]

Right, that works to some extent, but...

The point of having "what it is" in the name was to easily see what the service is meant for, but if you're using namespaces you essentially do not have the ability to see more then the service in the namespace or the global namespace (at least I see no pattern that works with --namespace or alternative flag for showing everything; if I dont specify the namespace I just dont see the service at all). So the problem is now you can't see everything else, which is annoying because I do very much want to see everything else so that nothing slips though the cracks (that's why I wanted the descriptive name to begin with). If I wanted to see a filtered view labels would have sufficed and if I just wanted a random name "www" + datetimeString() would have worked just fine.

Also, it doesn't really truly solve the problem with names, since technically you wouldn't want project+stage namespaces, but just project as the namespace, so that the namespace can be set on the project level (kubectl config or some such) and never be worried about again; and so that all stages are visible at once. So you would still have the "testing" in the name, and as such you're not far off from the problem again: "testing-www-varnish-cache" (too long)

Obviously the last example is a bit contrived, and I'm not against shortening names, it's just very annoying to have to do so and constantly worry about it. But worse of all, the limit propagates down to tool chains and may get shorter and shorter. To give a real world example I recently was in the process of building some tools to automate the process of using kubernetes so that team members have as simple as possible time working with it (ie. "you get the project from your machine to the kubernetes cluster with all the services, pods, etc with just this one command"). Things like a 24 character limit propagates into tools as (once you have to account for project names, staging names, etc) to something like "and then you pick a name that must be at most 4 characters long" which is just ugh! (and that's with using very abbreviated names everywhere!)

I should also mention that due to services having a 24 character limit it doesn't really matter much if other things don't have a 24 character limit, once automation is applied the logic will just easily propagate as such that you might as well think everything has a 24 character limit.

[thockin]

@srcspider I am not against increasing the length of namesapces (in fact it's on my TODO list for months, just have to do it carefully). If we increase it to 63 characters (DNS1123_LABEL) we just delay the problem. We can't expand beyond 63 characters or we can't use it in DNS. I'd really like to change it to DNS1123_SUBSDOMAIN (255, dots allowed, same as pods) but that has implications for things like env vars and DNS. Lack of time to think it through fully is the main reason we have not done this. @ArtfulCoder - one more for the list of DNS-related work :)

You're obviously aware of labels - labels are there exactly to carry "what it is" rather than embedding that in the name. We have some experience with the "jam it all in the name string", here at Google. Borg jobs have a string name field that is "a little long" because people did exactly this and kept needing just a few more character and just one more field.

Now, at the risk of telling you how to run your software, I will say that I think that @maklemenz is dead on - this is exactly what namespaces are for. You can simplify your whole stack by not needing to plumb the project and stage names though your code. Relative names are generally easier to manage.

As for cross-namespace visibility from the CLI: try the --all-namespaces flag.

As for "you wouldn't want project+stage namespaces", I'm not sure that's universally true. There's a lot of simplicity in being able to say "push a new update to www-testing and see what happens".

Anyway, this got long - I hope that you can find a solution in here, and if not - patches are welcome to expand services names - just know that you'll have to update tests and env var generation, at least. Not very hard.

[srcspider]

@thockin

As for cross-namespace visibility from the CLI: try the --all-namespaces flag.

Ah it's in the --help for get command and not global like the normal --namespace command. Oops

You're obviously aware of labels - labels are there exactly to carry "what it is" rather than embedding that in the name. We have some experience with the "jam it all in the name string", here at Google. Borg jobs have a string name field that is "a little long" because people did exactly this and kept needing just a few more character and just one more field.

My problem with labels is that I can't really stick into them information that's "identification" information since the names (at least for services) have to be unique. So this,

www   project=p1,stage=testing
www   project=p1,stage=production
www   project=p2,stage=production

...just doesn't work due to name conflict. I would have to, as mentioned earlier in this thread, generate a random name. And the problem with generating a random name is that its a bit tricky to match back in an automated process and a bit annoying when manually debugging or inspecting the state of the cluster (see bottom of post for solution I've settled on going for).

As for "you wouldn't want project+stage namespaces", I'm not sure that's universally true. There's a lot of simplicity in being able to say "push a new update to www-testing and see what happens".

It can be useful to allow developers to generate their own mini development server to test changes; or just for tooling. Before I wasn't aware of the --all-namespaces flag in get and with out it that would have been a bit annoying to get all instances of a project with out knowing what every single development server/stage is called. Now that I know of it, project+stage is not really that big of an issue, and probably more desirable.

---

Right now I'm thinking the most dumb way to solve this, in my projects at least, is to simply stick whatever name I want into a label "title" then hash it and use that as the service name. In the unlikely scenario where a hash conflict would occur it will just not allow the conflicting service to be created; which shouldn't be much of an issue even in automated processes (at least not in my use cases).

Would still be nice if this wasn't even something I would have to think about, but ohwell.

Probably go more crazy on it if that doesn't work out. Thanks for the help @thockin @maklemenz

[bacongobbler]

hey @thockin, was there a particular reason this issue was closed? If there's help needed to be done for increasing the service name length limitation, I'd be more than happy to make a PR to research and figure out a way to bump that limit!

We're creating applications with services attached to each replication controller, but the application name can only be limited to 24 characters so they're discover-able by other apps in the same namespace. Is there a technical limitation to bump it to DNS1123_LABEL for the time being?

[bacongobbler]

Anyway, this got long - I hope that you can find a solution in here, and if not - patches are welcome to expand services names - just know that you'll have to update tests and env var generation, at least. Not very hard.

Challenge accepted. :)