GlideinWMS The Glidein-based Workflow Management System

WMS Factory Design

Factory - Frontend Protocol

Jump to:
  1. Introduction
  2. Communication
  3. Authentication
  4. Condor Attributes
Factory Design Topics:

Introduction

This document describes the v3+ protocol between the GlideinWMS Factory and the supported Frontend services.

The protocol defines how the Frontend describes "what" needs to be done and the Factory knows "how" to do it. The VO Frontend, Corral Frontend, OSG, TeraGrid, and the Cloud all have special requirements where the frontends and users have some information on the "how" that is needed by the Factory. This means that the Frontend cannot pass information that will affect glidein submission; instead, they pick entry configurations that best suits their needs. The only exception is the ability of the Corral Frontend to pass a TeraGrid Project Id and either the VO Frotnend or Corral Frontend to pass VM Id and Type for cloud entries. The Frontends maintain the ability to affect glidein behavior with glidein attributes.

Communication between the Factory and Frontend

The Factory and Frontends communicate through the WMS Pool collector using HTCondor Classads. The Classads have an internal HTCondor type of "Master" except for the monitoring classad which has the "License" internal type. These classads contain information generated by both GlideinWMS and HTCondor.

  1. The Factory creates a Classad for each entry point to advertise that entry’s attributes.
  2. The Frontend creates a request Classad for a specific entry at a Factory from which the Frontend wants glideins. This Classad contains information needed to submit and start the glideins per the Frontend’s requirements.
  3. The Factory creates a Classad for each Frontend that it handles a request from with monitoring values.
  4. The Factory creates a global Classad that describes the global Factory parameters to be used by the Frontends.
  5. The Frontend creates a global Classad that contains the credential information for a Frontend for a specific Factory.

Two of the generated values are used in maintaining unique Classads in the Collector. GlideinWMS services provide Name and an internal classad type (Master or License). The Name is published in the Classad and can be queried in the Collector. The internal classad type is only used by HTCondor and is not published. The HTCondor Collector may also add other values to the request Classad that are used in determining uniqueness, such as MyAddress.

Authentication

If encryption is used, the encrypted identity in the Frontend request must match the AuthenticatedIdentity attribute inserted by the HTCondor Collector. This is fundamental for the security of the GlideinWMS protocol and is added to all Classads.

  • AuthenticatedIdentity = "user@node.domain.name"

HTCondor Attributes

Each Classad will contain additional HTCondor attributes automatically added by HTCondor. These are reserved names and cannot be overridden. The list below may be slightly different depending on what version of HTCondor is used, please see the HTCondor documentation for more information.

  • MyAddress = "<111.222.333.44:0>"
  • LastHeardFrom = 1292273491
  • UpdatesTotal = 5418
  • UpdatesSequenced = 5380
  • UpdateSequenceNumber = 1405
  • UpdatesLost = 1
  • UpdatesHistory = "0x00000000000000000000000000000000"
  • TargetType = ""
  • CurrentTime = time()