Multple Application Management

Hal Snyder hal@REDACTED
Thu Dec 6 17:19:22 CET 2001

Ulf Wiger <etxuwig@REDACTED> writes:

> The AXD 301 has functionality similar to what you describe. We have
> the possibility to add applications to an already running system,
> and if a new version of an already running application is made
> available, the software management component will figure out how to
> upgrade the system with it.

> This is done with the help of a layer on top of the release
> handler, and some design rules. One of the important things is
> that there must be a framework for initializing mnesia tables,
> and registering system resources (such as web menus and pages,
> alarm types, and distribution groups). It should also be
> possible, of course, to unregister the same, if an application is
> to be removed.
> This stuff could hypothetically be made available as Open Source,
> but we don't have the resources to do that at AXD 301.

I work with Martin at Vail and have been following this thread with
great interest. Like Vance, I'd like to think of an Erlang cluster as
a collection of servers onto which new apps are occasionally deployed
without restarting the nodes. I don't think this notion fits very well
with boot files.

I wonder about the feasibility of several nodes with very generic
startup config, plus a couple management nodes from which new code is
injected into the platform.

We use Erlang for several similar-looking apps - servers that do
various queries and resource allocation for our computer telephony
platform, a middle layer between speech servers and the resources they
need. It would be very interesting to learn more about the "extra
layer" mentioned above. Meanwhile, I wonder we shouldn't just
structure what is running on our servers as a single app, and add new
functions to it as needed. Does that make sense? I have a bad cold, so
it might not. :)

More information about the erlang-questions mailing list