[erlang-questions] upgrade path from R14B02 to OTP 17.5

[Fred Hebert]

On 06/15, Tanguay, Luc (A584369) wrote:
>We have a Erlang/OTP distributed system running on R14B02 Windows 2008 
>(32-bit).  We plan to upgrade to OTP 17.5 (64-bit).   The system 
>involves one big server that distribute files to up to 40 smaller 
>clients, three OTP applications, many TCP links between server and 
>clients, a small mnesia database, many calls to erlang:open_port/2 to 
>execute native Windows programs, etc.
>
>What is the safest upgrade path?  Go straight to OTP 17.5 or something 
>else.   Do I have to read all READMEs from R14B03 to OTP 17.5?
>

Hi Luc, there's a few interesting things to consider when going for such 
a plan.

The idea of going through a single big jump or many smaller ones will 
depend on a few things:

- Do you have a single big server? If so, what's the failover/takeover 
  story for this one? what are the requirements for uptime?
- Do you make use of OTP releases, or is it more of an ad-hoc deployment 
  system? How do you go about it?
- Do you have proper testing/staging servers to try things on?
- Do you have Erlang engineers on hand to handle this, or are you in the 
  (sadly somewhat common) situation where nobody knows the language, but 
  you still have to upgrade things?

Upgrading code itself can be done easily from small to larger versions 
by testing it locally and reading the READMEs for incompatible changes.

All in all, though, hot code loading works on Erlang code and NIFs, but 
doesn't work on the VM itself. While you can move from small release to 
small release (and also reload most standard libraries without much of a 
problem with relups and whatnot), the VM itself will need to go down and 
back up to upgrade the runtime system.

The safest upgrade path would be to be able to boot a second well-tested 
VM on a new code version on the side, and progressively move out 
responsibilities to this one until the old one is dead. The most brutal 
way to do it would just be to shut down the old node and boot the new 
one after.

Everything else is likely going to be a gradient in between those, in my 
experience.

Regards,
Fred.