RFC 1178: Choosing a name for your computer (1990)

I was expecting this to be a April Fools RFC [0]. I was disappointed when I checked the date.

[0]https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for...

One of the nicest "hidden" RFCs is RFC2468.

https://tools.ietf.org/html/rfc2468

("2 4 6 8, who do we appreciate")

We had to solve this problem for our TPU management system: https://www.tensorfork.com/tpus

The most sensible naming scheme for us was to distinguish them by index. But there were two important differences: TPUs have many sizes, which means some are larger than others; if you're using a v3-256, you're very likely the only researcher doing so. They are also distinguished by type; v3 is more powerful than v2. Finally, they are region-based; the less powerful v2's are in the US, whereas the v3 fleet is mainly EU based.

That led to the convention of tpu-v3-8-euw4a-1, tpu-v2-256-usc1a-0, and so on.

The "tpu-" prefix might seem redundant, but I find it's helpful in conversation. That's a personal preference though, and if I had to do it again I'd probably drop the tpu- prefix entirely.

I found this scheme was horrible for VMs though. TPUs are often used for specific training runs, and the scheme above is easily added to bash files / config scripts. But for VMs, you're often SSH'ing into them all the time.

Ultimately we started naming the VMs after the researchers who originally needed them. Our current primary training box is song.tensorfork.com, named after researcher songpeng who it was created for. So the SSH scheme was pleasant: song@song.tensorfork.com for him, shawn@song.tnesorfork.com for me, arfa@, aydao@, etc.

When arfa neded a VM, I simply named it arfa.

All other more complicated naming schemes failed with time. No one (including me) could remember long VM names, let alone ones with numbers in them.

The other scheme that persisted was to use anime characters, as emersion mentioned. Tensorfork itself runs off of vegeta, which is my personal Hetzner server. "goku" was one of our primary workhorses at one point, due to its large VM size.

Our final two VMs are named "test" and "nuck", which also seem to work quite well (much to my surprise). "Is test down?" is almost completely unambiguous. And it's easy to remember which one is which: "nuck" is in Canada, so therefore "test" is the one in europe.

A pattern emerges here: most of our VM names are short, four-letter identifiers: arfa, song, test, nuck, goku, with vegeta being the standout. All other conventions failed with time.

> Certain sets are finite, such as the seven dwarfs. When you order your first seven computers, keep in mind that you will probably get more next year.

We ran into this years ago when we named our machines after the Marx Brothers. We started out with Harpo, Groucho and Zeppo. When two more arrived, we used Chico and Gummo. IIRC we added Karl, Deutsche, Skid, Birth and Spencer before giving in and adopting a proper 'cattle not pets' convention (which, by the way, isn't covered by TFA).

This kind of naming is fine for small projects, and personal setups. In professional settings I would suggest using descriptive names and rely more on DNS.

It's not that I don't enjoy fun and personal naming schemes, it's just that it's a constant annoyance when dealing with a large number of different systems.

We've been hired to deal with different companies, who picks some random naming, cars, athletes, plants, cities and so on and it's confusing as hell. How am I suppose to remember that Ford and Volvo are your two web servers? Now I need to maintain a list mappings for your servers and look them up every time I need to change your web configuration. Just call them prod-web01.company.com and prod-web02.company.com, it's fine and everyone will be able to guess what those servers do.

You can also do web01.prod.company.com and web01.test.company.com, but while it looks cleaner (and I personally prefer it) is does hide the "prod" or "test" in most shells, so you constantly need to check that you're not messing with a production box.