16th
OTP Release Mgmt — Worth the Complexity?
Sort of an open question — anyone out there use the full, somewhat forbiddingly complex system for Erlang OTP releases? I finally think I at least understand it (thanks in no small part to Mitchell Hashimoto), but now that I do, I’m really not sure it’s worth it.
It seems like you put in place a bunch of nigglingly specific little config files, and then write a bunch of detailed specs for how code changes from one version to another. And that lets you do some nice upgrade/downgrade stuff (via further nigglingly specific “appup” files).
However, for our case, I think it maybe boils down to, either:
- The code change is very simple, and I can make it happen via the `code:load_file()` and `code:purge()` functions without restarting the server.
- The code change is complex, and I’ll just restart the server outright.
I mean, sure no 9 9’s uptime then, but I’m just not sure we need that (and if we do, we might be able to get it via some haproxy games instead).
The OTP system seems to me to take over a bit of what the OS does in Unix-land. In some ways, that’s good (the os-process-like Erlang processes are much better than shared-memory threads), but in other ways, now that I’m trying to manage a deployed server, it’s just, some things are a bit odd.
Anyone have any experience to share?
-Dan M
