3 ms·

I prefer to have mostly meaningless names for machines, and then having more names for them in DNS for their various functions. That way the functions can be mo

I prefer to have mostly meaningless names for machines, and then having more names for them in DNS for their various functions. That way the functions can be moved about the machines and if that's what you care about, then that's how you refer to them (deploy the app Foobar to web01 and web02), but when a machine goes down, you can shout, "clark is down!" web01/dns01/sto01 being down only means the service is down, whereas clark being down is something more severe. I manage my stuff with Ansible, which makes all this pretty easy.

anarcat 6y ago
here if "fsn-node-01" is down, we know it's a major ganeti node that dies. if "unifolium" dies, ... can you guess what happens? at first I couldn't either, but then I learned it's an old KVM node hosting a bunch of virtual machines, and it means pain, definitely something severe. yet it's not meaningfully different from "corsicum" dying (which is "just" a VM). adding meaning to machines reduces the cognitive burden (for oldies) and discovery burden (for newcomers) of figuring out what is what. that assumes you don't run services bare-metal. if you do, then maybe it makes sense to use meaningful names for those, but in general, I strongly try to avoid doing that anyways... and if I do, having a functional name for that metal is mostly harmless: if the function changes, the name changes, and then I need to do a name change, which I allow for. but that is rare, because if i dedicate full metal for a function, you can bet it won't be readily available for other purposes...