| 15 | | 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 : |
| 16 | | * `rpms.tpl` : contains all the RPMs required to run the service |
| 17 | | * `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. |
| 18 | | * `config.tpl` : contains all the configuration information required to configure the service (but not the included services) |
| | 12 | gLite templates are organized per ''service''. There are 3 categories of services, described in 3 different directories : |
| | 13 | * `glite` : one directory per gLite high-level service (WN, LFC, ...) |
| | 14 | * `lcg` : one directory per LCG high-level service (LCG CE and LCG RB) that are still part of gLite (gLite 3.0 only). |
| | 15 | * `common` : one directory per lower-level service (nfs, ssh, ...) used to configure high-level service. |
| 20 | | 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`. |
| 21 | | |
| 22 | | gLite services templates are organized in 3 main hierarchies : |
| 23 | | * `glite` : one directory per gLite high-level service |
| 24 | | * `lcg` : one directory per LCG high-level service (in fact LCG CE and LCG RB) that are still part of gLite. |
| 25 | | * `common` : one directory per lower-level service used to configure high-level service. |
| 26 | | |
| 27 | | In the `common` area, currently almost everything is coming from LCG configuration and is maintained manually. There is one exception, `common/glite` : this directory contains templates generated (by script) from XML files provided in gLite config RPMs. The generated templates conform to the service oriented layout, with 3 templates per service : |
| 28 | | * `config.tpl` : the entry point |
| 29 | | * `schema.tpl` : defines all the supported PAN resources/properties for this component |
| 30 | | * `defaults.tpl` : defines a sensible default value for each property, according to the content of XML file for the service. |
| 31 | | |
| 36 | | In addition, gLite templates include the following hierarchies, very close to what existed in LCG2 templates : |
| 37 | | * `machine-types` : one template per machine type. Intended to be included in a machine profile. |
| 38 | | * `vo` : all the VO related information (not yet based on namespaces). |
| 39 | | * `standard` : version of some critical standard templates. |
| 40 | | * `components` : description of NCM components related to gLite services used in other gLite templates (doesn't include OS related components) |
| 41 | | * `defaults` : templates providing sensible default values, mainly `site.tpl' for default site parameter values. |
| 42 | | * `repository` : template defining RPM repositories where gLite RPMs are located. '''Need to be edited to match site repository names.'''. |
| | 21 | In addition, gLite templates include the following hierarchies : |
| | 22 | * `machine-types` : one template per machine type describing configuration (including OS, VO configuration...) for a machine dedicated to the corresponding service. |
| | 23 | * `vo` : all the VO related information. |
| | 24 | * `components` : description of NCM components related to gLite services used in other gLite templates (doesn't include OS related components). |
| | 25 | * `defaults/glite` : templates providing sensible default values, mainly `site.tpl' for default site parameter values. |
| | 26 | * `repository` : template defining RPM repositories where gLite RPMs are located. ''May need to be edited to match site repository names.'' |
| | 27 | |
| | 28 | Inside each service directory, template names are quite standardized. Main templates, available in every service where it is relevant, are : |
| | 29 | * `rpms/arch/config.tpl` : contains all the RPMs required to run the service on the corresponding OS architecture (in gLite 3.0 templates where there was only one architecture supported, the corresponding template as `rpms.tpl`. |
| | 30 | * `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. |
| | 31 | * `config.tpl` : contains all the configuration information required to configure the service itself (but not the included services). This template is generally responsible for including the relevant RPMs related templates. |
| | 32 | |
| | 33 | 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 generally placed in the parent directory (e.g. `nfs`) and the template is generally named `base.tpl`. |
