[erlang-questions] Lightweight proper code update

[Jon Watte]

This looks great! We're currently in the throes of deciding between
rolling re-starts (and client re-connects) or in-place updates, and
this might skew the scales in favor of in-place.
There's still the whole question about how you unit test cross-version
updates effectively, but I don't expect anyone has a canned solution
for that...

Sincerely,

jw


--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world.
Nevertheless, whether we get there willingly or not, we shall soon
have lower consumption rates, because our present rates are
unsustainable.



On Sat, Feb 4, 2012 at 4:05 AM, Per Melin <per.melin@REDACTED> wrote:
> OTP release management, if you need most of the benefits it offers, can undoubtedly be very useful.
>
> But I believe that most of us don't need most of those benefits most of the time, and that all the careful administration it requires can be a hindrance and even a source of errors. Especially if you are running your code in-house and do frequent incremental releases.
>
> Unfortunately the next best thing is to restart the node or simply reload the changed modules and hope for the best. I think there is room for something better than that.
>
> I've toyed with different solutions and the best I've come up with is an application that does this:
>
> 1. Compare the loaded code with the beam files on disk to find modules that have been changed.
> 2. Use xref to figure out any dependencies between the changed modules (who calls whom).
> 3. Inspect the modules to separate supervisors, special processes like gen_server, and the rest.
> 4. Generate a script with appup instructions, based on the previous steps.
> 5. Use systools to compile this script to a lower level relup script.
> 6. Ask release handler to execute the low level script.
>
> You can find the code here. It is only about 200 lines.
> https://github.com/permelin/updo
>
> With this you don't get named releases or a bundled ERTS, but you do get the same code upgrade process as with a proper release; suspension of special processes, optional update of their states, updated child specs for supervisors, modules are reloaded in a logical order, etc. And it does not require you to keep app and appup files perfectly maintained or jump through any of the hoops otherwise associated with releases.
>
> There are however also some potential problems. At the top of my head:
> - To accomplish steps 5 and 6 I am calling functions in systools and release handler that are exported, but were most likely never intended to be used outside those applications.
> - xref will not always be able to find all cross-module calls, or do something about circular dependencies. Though I'm not sure it will do a worse job than a human manually writing appup instructions.
>
> Any other problems I've missed? Ideas? Questions? Wouldn't something like this be nice to have in OTP?
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions