release handling

Siri Hansen <>
Wed Oct 11 11:02:17 CEST 2000


Hi - I've been working with software upgrade for a while, and I've
prototyped a few releases for the purpose. Later, my project decided to
go for a simpler (not hot-swap) solution, but anyway - The OTP hot-swap
is actually quite cool - if not too well tested!

Vance Shipley wrote:
> What suprised us was that the release_handler did not
> allow us to build an initial system.  It must have a
> release upgrade specification file to complete the job
> and there doesn't seem to be a valid syntax for
> "upgrading" from nothing.

Wouldn't this syntax of the relup file be the same as upgrading from
nothing?
{"1.0",[],[]}.
This is what you get if you do systools:make_relup/4,and there are no
.appup files in the given path.

> I was also somewhat suprised that it packaged all the
> modules which were dependent including kernel and stdlib.
> This makes the standard release file much larger than
> needed.  I may change that one day but we generally stick
> to the supported path as much as possible because we
> create enough of our own problems. :)

All applications mentioned in the .rel file will be packed with
systools:make_tar/2, and the reason is that it should be opssible to
sell the release as a complete system - i.e. the customer does not have
to have Erlang/OTP installed before he can use the system.

> Now if the truth be known I usually skip the release_handler:unpack_release/1
> step and just untar it manually.  As far as I know that's all it really does.

Does the RELEASES file look the same if you untar the release manually?
I think that release_handler:unpack_release/1 also serves the purpose of
informing the release handler about the new release. If you untar the
release manually, you should also use release_handler:set_unpacked/2.


Sean Hinde wrote:
> Alternatively, has anyone found a simple mechanism to upgrade a single App
> without going through all the heartache of appup files etc?

As for using init:restart() for upgrade, I don't know to much about it.
It seems like init:restart() uses exactly the same boot arguments as
given when the node was started in the first place.

However, if you would like to try the release handler anyway - given the
SNMP application is delivered by OTP, the snmp.appup file allready
exists, so you only have to create the relup file
(systools:make_relup/4). 

When doing the upgrade itself, do release_handler:unpack_release/1 (or
untar manually and do release_handler:set_unpacked/2), then
release_handler:install_release/1 and release_handler:make_permanent/1.

/siri



More information about the erlang-questions mailing list