GlideinWMS The Glidein-based Workflow Management System

Search Results

Glidein Frontend

Design

Jump to:
  1. Implementation

Implementation

The current implementation of the VO frontend is Python based. It uses a tree of process like the factory does.


The sub-process (group) code is composed of 4 logical pieces:

  • An element that holds the user jobs Ads
  • A matchmaking procedure
  • A procedure that advertises the requests
  • ... and the glue that links the above together.

The top two elements simply contact the appropriate Condor Collector and store the data in memory.

The matchmaking procedure loops over all the factory ads and counts the number of idle user jobs that match the attributes of that particular factory entry point.

The matching expression is a Python expression, having as inputs

  • an object holding the job attributes, named job, and 

  • an object holding the entry point attributes, named glidein.

Both objects are dictionaries, with keys being attribute names, and values being attribute values.

A few examples:

job["CDFMaxHours"]<glidein["attrs"]["WMSMaxHours"]
job["HasData"] or (glidein["site"] in string.split(job["SitesWithRequiredData"]))
(job["Arch"] == glidein["Arch"]) and (job["gccVersion"]==glidein["attrs"]["gccVersion"])

Finally, the advertise procedure loops over the counts and converts them into appropriate Condor Class Ads.

For every factory entry classad, frontend also advertises resource classads to the User Pool

The glue code is responsible of parsing the input parameters, loading the configuration values and loop over the above steps.

The frontend also can handle multiple proxies. The proxy selection is handled by a plugin mechanism.