lcg-vo-env README
-----------------------------------------------------------------------------

Description
-----------
     lcg-vo-env is a program to generate the environment variables definitions
     needed for locating VO specific resources.  The idea is that lcg-vo-env 
     is evaluated in-line by the wrapper script that is submitted to the com-
     pute resource. It will set the relevant environment variables defined for
     the specified VO, within a namespace defined by the user.

Installation
------------
Building from CVS:

- check out the source, or unpack the CVS tar ball
- decide on your installation directory (default: /opt/lcg)
- install the package as root:

    make PREFIX=/opt/lcg install

- configure the VO settings on the machine by editing or adding the
  /opt/lcg/etc/vo-env.d/* files

Building an RPM from CVS:

- check out the source, or unpack the CVS tar ball
- decide on your installation directory (default: /opt/lcg)
- build the RPM (after having setup your ~/.rpmmacros file correctly!)

    make rpm

- which will leave the configures tar-ball and an RPM in the current 
  directory, named lcg-vo-env-0.1-1.noarch.rpm


DEPLOYMENT MODELS
-----------------------------------------------------------------------------
When migrating from the glite 3.0 sutuation, there are several scenarios:

(1) The users that submit jobs needing the special VO_<vo>_SW_DIR and
    VO_<vo>_DEFAULTSE vairables are made aware of this utility, and need
    to explicitly embed this in their job scripts. This gives them
    maximum flexibility to choose their own variable prefix, and possibly
    use more than one VO association at the same time. 
    Each user job should contain, near the beginning:

      eval `lcg-vo-env <full-voname>`

    The downside is that it requires user awareness, and is thus prone to
    mistakes.
    It may be an option for new VOs, that have non-letter characters in 
    their name. Note that by default, the environment prefix is determined 
    from the first component of the VO name, such that

      eval `lcg-vo-env myvo.example.org`

    sets the variables "VO_MYVO_SW_DIR" &c.

(2) The job wrapper, generated by the WMS, embeds the "eval `lcg-vo-env <voname>`"
    command just before the user's job in invoked. This way it's completely
    transparent to the user, but is does require a change in the WMS. The VO 
    name (in long format, like "myvo.example.org") is known to the WMS since 
    it's also used for matchmaking.

    In the long run, this is a favoured scenario, as it is both transparent, 
    and removed the necessity for each site to pre-install ALL POSSIBLE
    definitions for all environment variables for each and every VO.

(3) The transition scenario, where the lcg-vo-env utility is installed at 
    the sites, and the sites use this utility from "/etc/profile.d/..."
    to set all environment variable definitions.

    Thus, the configuration is in one place, but neither the WMS not the users
    need to know about it. 
    As it does not scale in the long run (just like the current solution does
    not scale), it does address the problems in having these environment variable 
    definitions hard-coded in YAIM.