# GlideinWMS The Glidein-based Workflow Management System

- Home
- Download
- Glidein Frontend
- WMS Factory
- Components
- Recipes
- FAQ

## Glidein Frontend

- Overview
- Details
- Configuration
- Design
- Monitoring
- Troubleshooting

### Details

Jump to:

1. Description
2. Hardware requirements
3. Downtime handling

## 1. Description

The Glidein Frontend (or VO frontend) will match user jobs with Glidein Factory ads. It is responsible for the submission of new glideins.

The VO frontend also keeps part of the configuration of a glidein, and can also provide the glidein Factory with the pilot proxies.

Note: if you are installing only the frontend and planning to connect to the OSG Factory, please refer to this section: Connecting to OSG Factory

## 2. Hardware requirements

CPUs | Memory | Disk
4 | 3GB | ~30GB

This machine needs 4 cores, preferable no more than 2 years old and a moderate amount of memory (3GB plus 2MB per running job should be enough).
The disk needed is just for binaries, config files and log files (30GB should be enough)
Hardware requirements depend on the expected load. With small loads or for test purposes one core and 1GB will suffice.

## 3. Downtime handling

The glidein Frontend supports the dynamic handling of downtimes.

You (Frontend admins) should add the following attribute for the Frontend tag in frontend.xml manually:

> <Frontend downtimes_file="frontenddowntime">

Downtimes are handled with

> gwms-frontend up|down|statusdown [-delay <delay>]

More advanced configuration can be done with the following script:

> /usr/sbin/manageFrontendDowntimes.py -dir /var/lib/gwms-frontend/vofrontend -cmd [command] [options]

You must specify the command to run. The valid commands are:

- add - Add a scheduled downtime period
- down - Put the Frontend down now(+delay)
- up - Get the Frontend back up now(+delay)
- check - Report if the Frontend is in downtime now(+delay)

Additional options that can be given based on the command above are:

- -start [[[YYYY-]MM-]DD-]HH:MM[:SS] (start time for adding a downtime)
- -end [[[YYYY-]MM-]DD-]HH:MM[:SS] (end time for adding a downtime)
- -delay [HHh][MMm][SS[s]] (delay a downtime for down, up, and check cmds)

This script can allow you to have more control over managing downtimes.

Please note that the date format is currently very specific. You need to specify dates in the format "YYYY-MM-DD-HH:MM:SS", such as "2011-11-28:23:01:00."