Multple Application Management

[Vance Shipley]

Martin,

Your question strikes a familiar chord with me.  My view of
the Erlang/OTP environment is that it should support multiple
applications in the same way that a Unix server does.  I 
should be able to hand you a release package to install on 
your node with applications A & B running and after installing
you'd now have A, B & C running.

The OTP provides some wonderful tools for building "applications",
packaging them into "releases" and installing them on running
systems handling necessary dependencies and code upgrades.  It
doesn't however work sjust described.

If you have built your applications using the design principles
of the application module you are able to load, start and stop
individual applications easily as in application:start(foo). 
You can even move distributed applications from node to node.
Using this you can have a dynamic set of applications coming
and going as you wish.

The problem is with the release_handler.  The view taken is a 
practical one which is directed at deploying embedded systems
as products in the field.  The design assumes that you have a
complete view of what is running on that system.  You create a 
foo.rel file which describes all the applications required and
the release package created includes all the files for all these 
applications including kernel and stdlib.

When I built my first release I ran straight into this difference
of mind set when I tried to install it.  I found that there was
no way to install it!  You can unpack it with 
release_handler:unpack_release(foo) but if you try to use
release_handler:install_release(foo) you will find that you need
a release upgrade script (relup).  There doesn't appear to be a
valid syntax for the relup file which will allow "upgrading" from
a non-existent release.

At this point the big picture came into view as I realized that 
there could only be one permanent release on the system.  Once
you have made a release permanent with 
release_handler:make_permanent(foo) that defines the boot file
which will be run at start up in an embedded system.  That boot
script is included in the release package so it obviously doesn't
know anything about your existing applications.

What I would like to do is to rewrite the release_handler module
to handle merging releases into one boot script.  When a new
release package is provided it could look at what other releases
are incorporated into the system and merge them together into one
boot script.  

Uffe described a manual way of doing this which is really the
definitive answer to your question.  It is much better to use the
systools to create a boot script from the release file than to try
and edit the boot script directly.  In this way you can edit the
foo.rel file and rerun systools:make_script(foo) each time the 
set of applications you want running permanently changes.

	-Vance


> On Mon, 3 Dec 2001, Martin J. Logan wrote:
> 
> >Hello,
> 
> >I am wondering if anyone can help point me in the correct
> >direction for the deployment of multiple applications on one
> >node. Currently I manage applications on a per application
> >basis i.e they are started individually. I start the runtime
> >system pointing it to the script and boot files that I
> >generated for that particular application using systools.
>