When I worked at Cornell, we had a habit of naming pairs or groups of machines that were related (eg. as failovers, or multimasters, or whatever) so that the gr

When I worked at Cornell, we had a habit of naming pairs or groups of machines that were related (eg. as failovers, or multimasters, or whatever) so that the grouping was obvious enough to stick. Hack/slash, itchy/scratchy, homer/bart/marge, etc. My officemate and I had Indigo2's named squish and squash, for example. I've done the same thing ever since, and if you look at truly huge deployments, you end up developing a lexicon that exists solely to indicate where and what a machine is. eg. "what's wrong with pyj121-200? the whole rack is flapping!" "oh it looks like a bad blade in pyextbr2" "well open a ticket to swap the blade tonight then! it's hanging index transfers!" Datacenter, rack, machine. Simple. Meanwhile, at some of the smaller deployments I've done, there are machines named after porn stars (lovelace/holmes were a couple of onsite/offsite RAID monstrosities; bildo/remsen were hot and cold firewall nodes), musicians (mingus/parker/coltrane/monk), and so on. Functional or physical relationships as indicated by lexical relationships are a relatively convenient shorthand, and if one machine turns into a farm, you have lovelace1, lovelace2, lovelace3... Just some musings. Thank god I don't work ops anymore.