VDT Working Group Meeting Agenda
22-Jan-2004, 11:00am Central Time

1. Repackaging the VDT in a different style. See proposal below.
2. Progress report on VDT 1.1.13.
3. Anything attendees would like to discuss.

Proposal for repackaging the VDT

A minor technical blip has caused me to think about how we package the VDT. The technical blip is just that, a blip with no big effect, but it started a chain of thoughts.

I would like to propose that, beginning with VDT 1.1.13, we package the VDT in a different way. I would like your feedback on this.

PROPOSAL

Part I: We propose replacing the three separate installations, VDT-Server, VDT-Client, and VDT-SDK, with a single installation called VDT. This basic installation will not have a distinction between servers and clients, but will lay down all the software on your system.

Upon installation, basic configuration for a working client will be done, but no servers will be configured or enabled

After installation, there will be a simple script (set of scripts?) that will let you set up the VDT as you like. These scripts will let you set up the servers, like the Globus gatekeeeper, GridFTP, MonaLisa, etc. If you do not run this script, they will not be configured.

(Minor variant: perhaps we maintain a VDT-Server and VDT-Client installation, but the only difference is that the VDT-Server installation runs the server configuration script. All the same software is installed.)

Part II: We will carefully maintain and advertise the individual software packages that are part of the VDT, and can will ensure that they can be installed separately. For instance, the VDT may contain packages named:

Globus Condor MonaLisa ... and a dozen more

and you will be able to install just Globus, or just Condor, if you like, by doing something like:

pacman -get VDT:Globus

This allows you to get subsets of the VDT. Note, however, that there still isn't a distinction between server and client software.

RATIONALE

1. It is becoming increasingly difficult to maintain a reasonable distinction between servers and clients, because there is a great deal of overlap between the two.
   1. Example 1: If you install Globus, you need most of Globus to be installed to get the basic functionality working. OK, users don't need the "globu_gatekeeper" binary, but they both need many shared libraries that are identical.
   2. Example 2: A lot of the same software is installed by both the VDT-Server and the VDT-Client. Both install FTSH, Condor/Condor-G, KX509, MyProxy, and GSI-OpenSSH. [1]
   3. Example 3: We want the server and client to install the same software, but it's a pain. For instance, we want PyGlobus in both the server and client, but it requires a lot of overlap so it currently is just in the server.
2. In past experience, sites that were client sites converted themselves to server sites because they suddenly realized that they needed extra functionality, like a GridFTP server. When everything is installed (but not configured) it is an easy switch.
3. We find it rare that someone needs a server but not a client.
4. Maintaining the distinction is becoming more work.
5. Disk space is cheap.
6. Users that want to install a subset of software will be able to install individual software packages without difficulty.

DISCUSSION

What do you think of this proposal? We are not tied to it, we are just contemplating it. I'm serious--we are flexible and want to meet our users's needs. Please let us know if this would be good or bad for you.

You can join in this phone conference to discuss this proposal.

Footnotes:

[1] It looks like the VDT installs a server and client version of GSI-OpenSSH, but they are the identical installation.