| | 8 | = Layout of gLite Templates = |
| | 9 | [[TracNav]] |
| | 10 | |
| | 11 | [[TOC(inline)]] |
| | 12 | |
| | 13 | This page contains a description of the layout of templates for gLite provided by QWG and how the site customization should be integrated. See page on template [wiki:Doc/TemplateCustom framework] for more details on template framework structure and site customization. |
| | 14 | |
| | 15 | Layout of gLite templates is based on PAN namespaces. This PAN feature brings an improved manageability. Among advantages, it allows : |
| | 16 | * More structured layout |
| | 17 | * Easier guess of where a template is located as its relative path is part of its name |
| | 18 | * Support for nodes running different versions of the gLite in the same cluster (not yet implemented) |
| | 19 | |
| | 20 | A part of the effort to ease management of templates, templates names are now organized based on a ''per service'' view. That means that there is one directory for each ''service'', with all the templates needed to configure the service contained in this directory (RPMs list, configuration information...). Inside each service directory, template names are now quite standardized. Main templates, available in every service where it is relevant, are : |
| | 21 | * `rpms.tpl` : contains all the RPMs required to run the service |
| | 22 | * `service.tpl` : contains all middleware components that need to be configured to run a specific service. This is mainly used for high level services, like CE, WN, BDII... This doesn't include any OS related information. |
| | 23 | * `config.tpl` : contains all the configuration information required to configure the service (but not the included services) |
| | 24 | |
| | 25 | Some services are made of several sub-components using different configuration information but providing no specific RPMs (e.g. `gridice`). In this case, `config.tpl` is replaced by one template for each sub-component, named after the sub-component name. If the sub-component requires some RPMs, a sub-directory is created (e.g. `nfs/client` and `nfs/server`) and if they share common configuration information, the template for this is placed in the parent directory (e.g. `nfs`) and the template is generally named `base.tpl`. |
| | 26 | |
| | 27 | gLite services templates are organized in 3 main hierarchies : |
| | 28 | * `glite` : one directory per gLite high-level service |
| | 29 | * `lcg` : one directory per LCG high-level service (in fact LCG CE and LCG RB) that are still part of gLite. |
| | 30 | * `common` : one directory per lower-level service used to configure high-level service. |
| | 31 | |
| | 32 | In addition, gLite templates include the following hierarchies, very close to what existed in LCG2 templates : |
| | 33 | * `machine-types` : one template per machine type. Intended to be included in a machine profile. |
| | 34 | * `vo` : all the VO related information (not yet based on namespaces). |
| | 35 | * `standard` : version of some critical standard templates. |
| | 36 | * `components` : description of NCM components related to gLite services used in other gLite templates (doesn't include OS related components) |
| | 37 | * `defaults` : templates providing sensible default values, mainly `site.tpl' for default site parameter values. |
| | 38 | |
| | 39 | To improve consistency in account IDs allocation, all the account related templates (user/group creation) is now in one directory, `common/users`, and is no longer part of service information. There is one template per user/group and the name of this template is generally the name of the user created. |
| | 40 | |
| | 41 | |
| | 42 | |
