GlideinWMS The Glidein-based Workflow Management System

Data exchange overview

In the previous section we described the general architecture of the WMS. Let now have a look at the type of information that the two pieces publish.

See here for a detailed description of the protocol.

The Glidein Factory Class-Ad

A factory publishes one class-ad per glidein entry. The class-ad contains

• the name of the glidein (and the factory),
• the attributes that describe the glidein,
• the list of parameters that the glidein accepts. All the parameters have also default values associated with them, in case a frontend does not redefine them, and
• the (optional) public key algorithm, ID and value, together with the supported symmetric algorithms, that the frontend can use to push back encrypted values.
• Plus a list of monitoring values (like how many glideins are already in the queues, etc.)

Look at the picture below for a generic description.



Please notice that the glidein attributes can be completely arbitrary; the only predefined attributes are the glidein and factory name, plus the convention that anything that starts with GlideinParam is a parameter and anything that starts with GlideinMonitor is a monitoring attribute.

Once the factory starts serving frontends, it will publish also another ClassAd for every frontend served. This ClassAd contains only monitoring information, and is not used by the glideinWMS itself.
Find below a graphical representation of these ClassAds.

The VO Frontend Class-Ad

A VO frontend will obtain the list all available glideins and select the ones that fit its needs, based on the published attributes. For each fitting glidein, a frontend class-ad will be published. Such a class-ad will contain

• the name of the frontend and a request ID,
• the desired glidein name,
• the (optional) URL and signatures for the frontend specific scripts and data,
• the desired rate and limits of glidein submissions,
• the glidein parameters (in clear),and
• the (optional) factory public key ID used, together with
  • the symmetric encryption algorithm and key,
  • the encrypted identity, and
  • the encrypted parameters.
• Plus a list of monitoring values (like how many jobs are currently running, etc.)

If encryption is used, the the encrypted identity must must match the AuthenticatedIdentity attribute inserted by the condor collector (needs Condor version 7.3.1 or better)

Have a look at the picture below for a generic description.

The most important parameters that the VO fronted sends to the factory are:

• The address of the User pool collector(s) - GLIDEIN_Collector.
• The pilot proxies. If present, these are always encrypted. Three types of information are sent:
  • Number of proxies sent - nr_x509_proxies
  • The proxy identifiers; given an identifier, the proxy DN must not change between updates. - x509_proxy_0_identifier ... x509_proxy_N_identifier
  • The security classes; proxies within the same class may have access to one another - x509_proxy_0_security_class ... x509_proxy_N_security_class
  • The proxies themselves - x509_proxy_0 ... x509_proxy_N
• The security name associated with the proxies - SecurityName. The factory uses it for frontend whitelisting. If present, it is always encrypted.

The picture below shows this in a graphics format.

In the current implementation, the only glidein rate setting parameters supported are ReqIdleGlideins, that tells the factory how many idle glideins to keep in the queue at any given time, and ReqMaxGlideins, that tells the factory to stop submitting new glideins when the number of running glidiens reaces that level. Future versions may contain more sophisticated controls, like the maximum number of glideins to keep in the queue or the maximum rate at which the glideins should be submitted.