[erlang-questions] Lightweight proper code update

[Tim Watson]

This looks very interesting, I will have a play. I would definitely like to
see this kind of thing either move into OTP proper, or be based on
supported/documented OTP features - e.g., if the OTP team made the extended
API for systools/reltool official.

Oh and personally I would prefer updo:dry_run(details) or updo:dry_run(high
| low) to updo:dry_run_low, but that's just a matter of taste. ;)

Nice work.

On 4 February 2012 12:05, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120204/d1e73a72/attachment.htm>