jungerl/builder example?

Ulf Wiger ulf.wiger@REDACTED
Tue May 11 17:51:07 CEST 2004

On Fri, 07 May 2004 02:29:50 +0200, Gerd Flaig <gefla@REDACTED> wrote:

> perhaps I should clarify this a little:
> I'm specifically looking for information regarding real-world usage of
> SASL. How do you manage releases and up/downgrades?

At least in AXD 301, downgrades are simply performed by installing
a mnesia fallback and rebooting the system. ;)

Upgrades are hopefully perfectly smooth, but the sheer size of the
AXD 301 code base (> 1000 modules, 2 million lines of code) makes
that a challenge sometimes, so we have several different kinds of
upgrade actions:
- smooth
- restart one processor at a time
- restart only user applications on one processor at a time
- restart user applications on all processors simultaneously
- reboot all processors
- export configuration data via SNMP, convert it off-line,
   re-install the system, re-import the configuration data
   (OK, that's only been done once, when all else failed, in a
    fairly early release of AXD 301.)

> We're currently creating glue scripts to automatically determine
> applications that changed between releases (based on release tags in
> CVS), bump their versions, insert app versions in .rel files, make the
> relup file and finally the tar archive.
> Hmm. Maybe there even is a way to automatically create appup-skeletons
> based on the list of changed modules, tags in the module source, xref,
> ...?

Indeed. In AXD 301, appup files are normally generated automatically,
based on the application version (which is automatically stamped in
the app file based on ClearCase release labels.)

We always upgrade a whole application at a time. This makes the
appup file fairly easy to generate, since the default sequence
is rather obvious:
- pre-load all modules in the application
- suspend all processes using any modules in the application
- load the code
- call code_change functions
- resume the processes
- synch with other processors involved.

Then there are all sorts of special hooks to defer some code changes
until last in the upgrade, to never resume some processes if there
will be a reboot at the end, to call code change functions in
applications that have no processes, etc. These hooks are defined
as special environment variables, and are used if found in the
app file.

In order to allow designers to release their own hand-crafted appup
files, we put the automatically generated appup files on /tmp/
Each ebin directory either has a real appup file present, or a
symbolic link to /tmp/<App>.appup (which will not exist until it's
generated during upgrade.) This is done because (1) the code tree
is read-only for the applications, and (2) OTP doesn't allow
patching of app and appup files.

Ulf Wiger

More information about the erlang-questions mailing list