Creating gLite Templates

Table of Contents

1. gLite Service Templates
2. Where to Find Documentation
3. How to Start with a New gLite Service
   1. RPMs
   2. service.tpl
   3. config.tpl
   4. Machine type
4. Documenting Configuration of a gLite Service

This page contains guidelines and receipees to create and maintain templates related to gLite services. This is not The Definitive Guide as there is no general rule that works with every service. Almost every gLite service has some specifics.

gLite Service Templates

QWG templates for gLite are organized in two categories of services :

• high-level services : the services exposed to the user like CE, SE, BDII, WMS... Configuration for these services are in glite/ directory of grid templates for a specific gLite version.
• low-level services : all the underlying services used by high-level services, like gridmap, globus, gip or configuration shared between several services like security, torque, nfs...

For complex services, like WMS, it may happend there is both a high-level service and a low-level service called wms. In this case, the low-level service is service configuration part that is used by other high-level service. The bottom line is that high-level services are not cross-referencing each others, with the exception of BDII high-level service which is included in most of the others.

In addition to templates describing services, there is generally one template called a machine type template, sitting in machine-types directories of grid templates. This template does everything required to configure a machine with the corresponding high-level services, including OS configuration. When a high-level service has several configuraion variants (e.g. WMS and/or LB, DPM head node or disk servers), there is generally only one machine-type template with a variable allowing to select the appropriate variant for one specific machine.

Each service description is arranged basically around the same layout, with generally at least 3 templates for high-level services:

• config.tpl: this templates does all the configuration specific to the service, whether high-level or low-level but doesn't take care of loading packages used by the service and is not responsible for configuring other services used by the service. In some services, the name of the template may be different, if more appropriate.
• service.tpl: this template configures every low-level service used by the high-level service, including the specific configuration (config.tpl) and RPMs (`rpms/config.tpl) for the service. This template exists only for high-level services and is the main entry point for configuring the service.
• rpms/config.tpl : this template is responsible for adding all the packages (RPMs) used by the service. It seldom exists in low-level services but is always present in high-level service. Generally this template mainly includes another template which does the real work and is architecture specific. The architecture specific templates must be in a directory rpms/arch (e.g. rpms/x86_64) and is generally called config.tpl but may have another name if more appropriate, in particular in services supporting several variants (like DPM, dCache...).

Where to Find Documentation

How to Start with a New gLite Service

One important design choice in QWG templates is to try as much as possible to avoid interdependencies between services to ensure the final configuration is not dependent of the order the services have been configured. This is not always possible (e.g. BDII and GIP are by design quite inter-dependent) and in this case it must be clearly documented in the templates.

Note: QWG configuration relies heavily on global variables to customize a service configuration. It is important to ensure there is no conflict between variables used by two different services. The good practice is to prefix any variable used by a service by something identifying unambiguously the service like WMS_, LB_, SEDPM, BDII...

RPMs

For each gLite service in glite/ directory, there is a list of the required RPMs for the service. This list is mainly generated from official list supplied by ​gLite with the release. It generally requires some manual tuning to solve some missing dependencies in the list provided by gLite. After the initial release, this list should not be edited, except for adding a new RPM required by an update. Replaced RPMs must be handled by update related templates.

To generate the template from the gLite supplied list, you need to use src/utils/misc/createPackagesTemplate script provided with SCDB. The steps are :

• Download the official list from ​gLite site. For example for gLite 3.1 WN, download ​http://glite.web.cern.ch/glite/packages/R3.1/deployment/glite-WN/3.1.0-1/glite-WN-3.1.0-1.html.
• Process this file with src/utils/misc/createPackagesTemplate script :

  src/utils/misc/createPackagesTemplate --rpmlist glite-WN-3.1.0-1.html \
                                        --template cfg/grid-3.1/glite/wn/rpms/i386/rpms.tpl \
                                        --namespace glite/wn/rpms/i386
  

service.tpl

config.tpl

Machine type

VO config

Documenting Configuration of a gLite Service

Whether configuration for a gLite service is modified/enhanced or wether configuration for a new service is added to QWG, it is very important to document them immediatly on the [lcgqwg:wiki:WikiStart LCG QWG wiki]. There are potentially 2 places where the change/addition must be documented:

• gLite Customization: this page is an How-To page describing configuration of a particular service. Main entries in this page are mainly high-level services, with a few exceptions like NFS, Torque/MAUI, MPI. The most important information there is the officially supported variables available to customize the service. Information is added here as soon as (sometimes a little bit before!) the new configuration is committed to trunk.
• Release Notes: this page is a log (in reverse chronological order) of every major change/addition to the templates. It should be a short description linking to gLite Customization for details. Every entry in the log starts with the version of QWG templates where the change was introduced. The version used when the entry is added, as explained in the page, is always the next version to be released : don't wait for the official release to add entries!