[Erlyaws-list] integrating yaws into OTP nodes

[Hal S. <ha...@va...>]

Most new Erlang applications we write for our telephony platform
use yaws for status and control. We needed to work in a scheme of
configuration management to support this practice. Here's what we
have so far.

I wonder if anyone else is doing something similar and has comments.

This is gruesome and boring CM, but if we don't make it sensible
at our site at the outset we will make a zoo of varying ad hoc
directory setups and soon lose the ability to reuse code, simply
because of stupidity in the build system.

We keep source in CVS, but that doesn't really matter for this
discussion. Also unless you use pkgsrc, you'll be more accustomed to
/usr/local/ than /usr/pkg/ for site additions to the OS.


1. There are applications and releases.

Applications in our CVS tree are like the lib apps in the Ericsson
distribution.

Releases on the other hand combine several apps and libs into a single
node, with .boot and .script files and so on.


2. There are development and production modes.

When developing, a programmer works in "local mode" from his/her home
directory, inside a CVS work area. Non-Ericsson libs and yaws pages
and .boot and .script all come from the local sandbox.

In production, files are placed under /usr/pkg/vail/otp and run as
user "erts".


3. The layout.

Here is what happens in the programmer's CVS sandbox
(* marks derived files, -> marks symlinks):

otp/
  lib/
    my_app/
      vsn.mk
      src/
        xxx.app.src
        xxx.appup.src
        xxx.erl
      ebin/
        xxx.app*
        xxx.appup*
        xxx.beam*
      priv/
      yaws/
        yyy.yaws
      ...
    yaws/
      src/
      ebin/
      www/

otp/
  releases/
    my_app_rel/
      vsn.mk
      zzz.config.src
      zzz.rel.src
      yaws.conf.src
      zzz.rel*
      local/ (everything under here is generated by gmake)
        yaws.conf* (docroot points to this directory)
        zzz.config*
        zzz.boot*
        zzz.script*
        zzz.sh* (shell script to start the node in local mode)
        my_app -> ../../../lib/my_app/yaws
        my_other_app -> ../../../lib/my_other_app/yaws        
        index.html* (simple nav to all apps on the node)

Production:

/usr/pkg/lib/erlang/lib (usual Ericsson distribution) 
/usr/pkg/vail/otp/ (site files in production)
  lib/
    my-app-1.1/
      src/
      ebin/
      yaws/
  rel/
    my_app_rel-1.2/
      my_app_rel.boot
      my_app_rel.script
      my_app_rel.config
      my_app_rel.sh
      yaws.conf (docroot points to this directory)
      my_app -> ../../lib/my_app-1.1/yaws
      my_other_app -> ../../lib/my_other_app-2.5/yaws
      index.html (simple nav to all apps on the node)

We are just rolling out this arrangement. It permits multiple versions
of releases and libs to coexist. Users do not need to know version
numbers when typing URLs.

Normally we like all logs in /var, typically a filesystem for
scribbling. But here we wanted to keep installation simple, and for
that it helps to put all files associated with a release under one
directory.

We use autoconf and NetBSD's cross-platform pkgsrc to package and
deploy our OTP nodes.