[evla-sw-discuss] Code management

[Barry Clark]

There seems to be general agreement that there needs to be a
set of alternate images, the current production software, the nightly
compile software, an old version (probably just the last production 
version when that is updated), and people's personal version.
There is a slight complication, in that how often the production version
is updated may depend on the package.

For shellscripts, C executables, python, perl, etc. the only reasonable
alternative is to have separate directories for each of those.
Rich favors a scheme for Java involving keeping all the jar files
in the same directory, and distinguishing the above with different
names, and with the provision that the mapping may change from time
to time.  It is possible to make this scheme look as if the jar
files were in the same directories as we provide for other languages
by making, and having Rich maintain, symbolic links to the appropriate
jar files in those directories.  It bothers me a little that the 
infrastructure is language dependent, but it is certainly workable.
Opinions from others on the matter?

The preference is that selection of the version should be via an
environment variable or a parameter supplied to the script or both.  
(I favor the former because the script may need other parameters,
which could get confusing.)

I propose to ask helpdesk to create /opt/local/evla.  This area
would only hold scripts as simple as possible (unfortunately, this
isn't very simple), to execute software from one of the more easily
changeable areas.  I give an example below of what a particularly
simple java launch script might look like.

We will need to create a few new disk areas to hold the executables
or symbolic links.  I suggest the following:
/home/asg/bin/new
/home/asg/bin/std
/home/asg/bin/old

/home/mchost/evla/bin/std

The last would be updated by a cron file (or as part of the creation
of the std software) which copies changed versions of the files from
/home/asg/bin/std to that local area on the evla subnet.

/home/asg/bin/new would contain (for now) symbolic links generated
by commands like
ln -s /home/asg/.maven/repository/nrao/jars/evla-commons-0.3-SNAPSHOT.jar \
   evla-commons.jar

/home/asg/bin/std would contain the equivalent symbolic link
ln -s /home/asg/.maven/repository/nrao/jars/evla/evla-commons-0.3.jar \
   evla-commons.jar

Now the promised example.  The program is a stupid little java program
that reads data from the Atmospheric Phase Interferometer and munges it
around to make a guess at what the atmospheric conditions are likely to
be an hour from now.

It is particularly simple program in that it only accesses a single jar
file.

If there is nothing special in the environment, that jar file is the
one pointed to by the symbolic line /home/asg/bin/std/evla-scheduler.jar.
If there has been a 'setenv EVLASOFT NEW', the jar will be the one
pointed to by symbolic link /home/asg/bin/new/evla-scheduler.jar.
Similarly if there has been a 'setenv EVLASOFT OLD'.  If the file is
executed on a machine on subnet 10.80, instead of /home/asg/bin/std/,
the directory /home/mchost/evla/bin/std would be accessed.  Alternately,
the user can specifiy directly which jar file is to be used, by
saying 'setenv SCHEDJAR <file name of the jar he wants>'.  This lets
one use the standard launch script with personal versions of a named
jar.

Essentially similar logic can be used to launch C executables, perl
scripts, shell scripts, or utility programs.

#!/bin/csh -f
#
if (! $?EVLASOFT) then
    set EVLASOFT = STD
endif
switch ( $EVLASOFT )
  case NEW:
    set JARHOME = /home/asg/bin/new
    breaksw
  case OLD:
    set JARHOME = /home/asg/bin/old
    breaksw
  case STD:
  default:
    set host = `/bin/uname -n`
    set inetaddr = `ypmatch $host hosts`
    set subnet = `echo $inetaddr | sed -e 's/^...../&#/' -e 's/#.*$//' `
    if ($subnet == "10.80") then
        set JARHOME = /home/mchost/evla/bin/std
    else
        set JARHOME = /home/asg/bin/std
    endif
    breaksw
endsw 
if ( $?SCHEDJAR ) then
    set schedjar = $SCHEDJAR
else
    set schedjar = $JARHOME/evla-scheduler.jar
endif

set MAIN_CLASS = edu.nrao.evla.scheduler.Api

set APP_CLASSPATH = $SCHEDJAR

exec $JAVA -classpath $APP_CLASSPATH $MAIN_CLASS