Frontend Design Overview
The current implementation of the VO Frontend is
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 HTCondor 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
HTCondor Class Ads.
The glue code is responsible of parsing the input parameters, loading the configuration values and loop over the above steps.
[GSI proxies are deprecated]The Frontend also can handle multiple proxies. The proxy selection is handled by a plugin mechanism.