Changes between Initial Version and Version 1 of Development/Templates/BestPracticies


Ignore:
Timestamp:
Oct 8, 2010, 2:24:57 PM (15 years ago)
Author:
/O=GRID-FR/C=FR/O=CNRS/OU=LAL/CN=Michel Jouvin
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Development/Templates/BestPracticies

    v1 v1  
     1= Best Practicies for Contributing QWG Templates =
     2[[TracNav]]
     3
     4[[TOC(inline)]]
     5
     6
     7== Template names and namespaces ==
     8
     9QWG templates describe how to configure ''machines'' running a certain set of ''services''. A ''machine'' includes everything from hardware configuration to the services run on the machines, including the OS and RPMs used. A ''service'' is any part of the configuration that may described as a unit and that may be used by other services. It is not related to a particular daemon/service. QWG templates distinguish between two types of services:
     10 * Low-level services: services whose configuration don't rely on another services. In the gLite templates, they are found under the `common` namespace (one specific namespace per service).
     11 * High-level services: services who configuration involves the configuration of underlying (low-level) services. In gLite templates, they are found under `glite` (or `lcg` for legacy services) namespace, with one namespace per service. In standard templates, they are found under the `features` namespace, with one namespace per service.
     12 
     13In QWG templates, there are a few conventions on template names:
     14 * For templates configuring a low-level service, the main template describing the configuration must be called `config.tpl`.
     15 * For templates configuring a high-level service, the main template describing the configuration must be called `service.tpl` and mainly includes the configuration template (typically `config.tpl`) of every low-level service required. A service `config.tpl` must also exist to do the configuration specific to the high-level service but is not intended to be called directly.
     16 * Some services may require an early configuration step to be done generally during the OS configuration. When this is the case, the template used for this early configuration step must be called `init.tpl`.
     17 * RPMS required by a particular service or OS component must be described in a dedicated template. The recommended name of this template varies depending whether all the RPMs are architecture independent or not.
     18   * If the RPM list contains only architecture independent RPMs or if there is not and will not be any support for multiple architectures, the template must be called `rpms.tpl`.
     19   * If the RPM list has some dependencies on the architecture, the template must called `config.tpl` and sits into a `rpms` namespace under the service namespace. Generally the `rpms` namespace contains one sub-namespace per architecture (whose name is the architecture) and this sub-namespace contains a template `config.tpl` listing the architecture-specific RPM required by the service. This architecture-specific `config.tpl` is not intended to be called directly but must be included by the main (architecture-independent) `config.tpl`.
     20
     21
     22== Variables ==
     23
     24QWG templates make an intensive use of variable. To avoid name collisions, the following convention has been established:
     25 * These variables being global, their name must be in uppercase.
     26 * The variable name '''must''' start with the service name followed by an `_` (underscore) they apply to. For historical reasons, some variables don't adhere to this convention but new variables must. When contributing to the configuration of an existing service, please adhere to the name prefix already used.
     27 * The variable name prefix used must be consistent across the whole service configuration
     28 * Some examples: `DPM`, `LCGCE`, `CREAM`, `NFS`...
     29
     30Some variables have a specific purpose and can be found in many different services:
     31 * `xxx_CONFIG_SITE`: the value is a template name describing the site-specific configuration of service. For historical reasons, the variable name suffix is `CONFIG_SITE` and not `SITE_CONFIG`. Please adhere to this convention.
     32
     33Variables intended to be customized by sites '''must''' be documented in the `Documentation` section of this wiki.