Skip Menu | Logged in as guest | Logout
 
Ticket metadata
Id: 4600
Status: resolved
Priority: 3/0
Queue: vdt-internal

Fixed in: (no value)
Fix scheduled: CUR

Owner: Alan De Smet
Requestors: Alain Roy
Cc:
AdminCc:

New reminder:

Created: Fri Dec 19 16:47:03 2008
Starts: Not set
Started: Wed Jan 28 14:55:32 2009
Last Contact: Not set
Due: Not set
Closed: Fri Jun 05 16:55:12 2009
Updated: Fri Jun 05 16:55:12 2009 by adesmet



History Brief headersFull headers
Subject: Add OSG Matchmaker to the VDT
Download (untitled) / with headers
text/plain 2.2k
We want to add the OSG Matchmaker to the VDT.

Mats Rynge <rynge@renci.org> is the contact.
Documentation is at: http://osgmm.sourceforge.net

Here is my understanding of what the OSG matchmaker is.

The OSG matchmaker can be installed on top of the OSG client. It relies
on Condor-G. It boils down to a Java daemon and a configuration file.

The Java daemon sucks in site ClassAds. It usually gets them from OSG's
Resource Selection Service (ReSS), but that's configurable. It takes the
subset of ads that indicate that a site supports a certain VO then edits
them slightly. Most of the edits are automatic, but users can also add
attributes to specific sites and add entire sites. The Java daemon does
this periodically.

Then the user just uses Condor-G with matchmaking to run jobs.
Periodically the Java daemon will update the site ClassAd's rank based
on how well it thinks a site is responding, to encourage jobs to go to
one site or another.

Some details:
- It reduces the number of ads a lot, like from 15,000 to 50.

- We need to edit the Condor config to allow condor_advertise to work.
Right now the recommendation is to add FS security as a method. We
should talk to Condor folks to make sure that's what we want.

- The daemon could run as the daemon user, but it is capable of
submitting verification jobs (check a site's setup, like OSG_APP_DATA)
and maintenance jobs (clean up home directory). These require a home
directory and a proxy, so the daemon user probably isn't appropriate.
Proposal: we install as the osgmm user if it exists, otherwise the
daemon user. We should have a configure_osgmm that lets the user be
changed. It should fix permissions as appropriate.

- The OSG mm user does need a full shell, even if it's the daemon user.

- Nothing watches the OSG matchmaker. Should it run under the
condor_master? Can we run things like this as a specific user separate
from the Condor user? That would be cool.

- It has a liberal, BSD-style license.

- Mats will provide supports. There is a mailing list on sourceforge.

- Can we test it? We could theoretically check it to make sure that it's
getting ads into the local collector, but it relies on ReSS being up and
running. Can we do a more local test?

- The OSG matchmaker is mostly in maintenance mode, but Mats does
occasional development as needed.