Note: This web site is only kept up to date for OSG Software
1.2 (VDT 2.0.0). If you are looking for information for the most recent
release, the RPM-based OSG Software 3.0, please see
the OSG documentation web site
VDT Working Group Meeting Minutes
- Carey Kireyev (UW Madison)
- Nate Mueller (UW Madison)
- Alain Roy (UW Madison)
- Scott Koranda (UW Milwaukee)
- Bockjoo Kim (Flordia)
- Ed May (Argonne)
LIGO and VDT
Recently a effort has been started among LIGO participant to create their own distributions
of grid software. These will use Debian, Fedora and MacOS native formats (deb, yum and ??? respectively)
instead of the VDT distribution (pacman). The main reasons are as follows:
- VDT Currently doesn't offer explicit support for Debian Linux
- VDT uses pacman instead of the Debian native packaging format
- The LIGO participants already use other collaboration-specific tools which they
plan to distribute in the native Debian (and Fedora) format.
LIGO as a whole may still use VDT in the following ways:
- Server-side installations will be based on VDT
- Client-side installations for Solaris will be VDT-based
- Some inidividual components will be taken from VDT and re-packaged using abovementioned
native packaging formats
VDT will work to figure out the feasibility of support for Debian Linux.
VDT will also continue discussion with LIGO to determine whether there's a way for LIGO
to use VDT in ways other than proposed here.
Input on VDT Release PolicyThe frequency of releases
The degree of change in software that incremental stable releases may contain
The amount of testing that is desired from a stable release
VDT has asked attendants to share their thoughts on VDT release policy, particularly issues such as:
Agrees that incremental version of stable releases should only include bug fixes. No new
components and/or features should be added
Ed also notes that lots of clients install Condor separately from VDT.
Ed recommends site verification script (site_verify) to be used on grid sides to help
determine "worthiness" of a VDT release. Potentially the script should also make it into VDT.
Grid3 doesn't follow VDT release schedule, so there's not as much of a pressure to coordinate
VDT releases with Grid3 needs.
As a rule of thumb the following schedules were proposed:
development releases - once every two months
stable releases - once every six months
VDT also will ask for input from heads of important grid projects: Grid3, LIGO, EGEE, LCG, etc.
VDT has also discussed augmenting its testing procedures in the following ways:
- Include more component tests (e.g. VDS, MonaLisa) into VDT test harness / nightly installation tests
- Run Nate's "hello, grid" batch test every night
- Discuss the possibility of deploying the latest stable VDT release candidate on UW Globus submit machines (north.cs.wisc.edu and/or south.cs.wisc.edu)