Changes between Version 5 and Version 6 of Doc/gLite/TemplateCustomization/Services


Ignore:
Timestamp:
Feb 10, 2011, 4:39:35 PM (13 years ago)
Author:
/C=UK/O=eScience/OU=CLRC/L=RAL/CN=richard hellier
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Doc/gLite/TemplateCustomization/Services

    v5 v6  
    1212__Base template__ : `machine-types/ce`.
    1313
    14 QWG templates can handle configuration of the LCG (gLite 3.1 only) or the CREAM CE and its associated batch system (LRMS). Most of the configuration description is common to both type of CE. In gLite 3.1, CE type defaults to LCG for backward compatibility whereas in gLite 3.2 it defaults to CREAM, the only CE availabe. CE type selection is done with variable `CE_TYPE` which must be `lcg` or `cream`. This variable is ignore in gLite 3.2.
    15 
    16 LRMS selection is done with variable `CE_BATCH_NAME`. '''There is no default'''. The supported LRMS and associated values are:
     14QWG templates can handle configuration of the LCG (gLite 3.1 only) or the CREAM CE and its associated batch system (LRMS). Most of the configuration description is common to both type of CE. In gLite 3.1, CE type defaults to LCG for backward compatibility whereas in gLite 3.2 it defaults to CREAM, the only CE available. CE type selection is done with the variable `CE_TYPE` which must be `lcg` or `cream`. This variable is ignored in gLite 3.2.
     15
     16LRMS selection is done with the variable `CE_BATCH_NAME`. '''There is no default'''. The supported LRMS and associated values are:
    1717 * Torque/MAUI: `torque2`
    1818 * Condor: `condor`
    … …  
    2727
    2828In addition, 2 other variables independent of the LRMS are available:
    29  * `CE_PRIV_HOST`: alternate name of CE host. Used in configuration where WNs are in a private network and CE has 2 network names/adresses. This variable is not (yet) supported with multiple CEs.
     29 * `CE_PRIV_HOST`: alternate name of CE host. Used in configuration where WNs are in a private network and CE has 2 network names/addresses. This variable is not (yet) supported with multiple CEs.
    3030 * `CE_WN_ARCH`: OS architecture on CE worker nodes. Due to limitation in the way this information is published now, this is a CE-wide value. If you have both 64-bit and 32-bit WNs, you must publish 32-bit (`i386`). Default value is based on CE architecture.
    3131
    3232=== Sharing WNs between several CEs === #CESharingWNs
    3333
    34 QWG templates allow to configure several CEs sharing the same WNs. They must share the same gLite parameters and the variable `CE_HOSTS` must contain all the CE host names. They can be LCG CE and/or CREAM CE. If you want to mix LCG and CREAM CE, it is recommended to maintain a separate list of for each CE type and build `CE_HOSTS` by merging them as in the following example:
     34QWG templates allow you to configure several CEs sharing the same WNs. They must share the same gLite parameters and the variable `CE_HOSTS` must contain all the CE host names. They can be LCG CE and/or CREAM CE. If you want to mix LCG and CREAM CE, it is recommended to maintain a separate list of for each CE type and build `CE_HOSTS` by merging them as in the following example:
    3535{{{
    3636variable CE_HOSTS_CREAM ?= list('cream1.example.org','cream2.example.org');
    … …  
    5959When NFS is used to share sandbox area, the [/wiki/Doc/gLite/TemplateCustomization/General#SharedFileSystems usual NFS variables] apply to define NFS version to use, mount options...
    6060
    61 ''Note: sandbox area sharing is configured independently of other file systems specified in `WN_SHARED_AREAS`. Sandbox areas are normally not specified in `WN_SHARED_AREAS` but if they are, this takes predence over the specific configuration done with `CREAM_SANDBOX_MPOINTS`.''
     61''Note: sandbox area sharing is configured independently of other file systems specified in `WN_SHARED_AREAS`. Sandbox areas are normally not specified in `WN_SHARED_AREAS` but if they are, this takes precedence over the specific configuration done with `CREAM_SANDBOX_MPOINTS`.''
    6262
    6363When using sandbox sharing with several CEs (specified in the same `CE_HOSTS` variable), it is important to define a distinct mount point for each CE.  Below is an example showing how to define `CREAM_SANDBOX_MPOINTS` based on `CE_HOSTS_CREAM`:
    … …  
    145145 * `WN_CPUS_DEF` : default number of CPU per worker node.
    146146 * `WN_CPUS` : a nlist with one entry per worker node (key is the node fullname) having a number of CPUs different from the default.
    147  * `WN_CPU_SLOTS` : number of job slot (Torque processors) to create per physical CPU. Default is 2 to allow both a normal job slot and a standing reservation reserved for short deadling jobs.
     147 * `WN_CPU_SLOTS` : number of job slot (Torque processors) to create per physical CPU. Default is 2 to allow both a normal job slot and a standing reservation reserved for short deadline jobs.
    148148
    149149For more details about all of these variables, their format and their default values, look at template defining [source:templates/trunk/grid/glite-3.1/defaults/glite/config.tpl default values] for gLite related variables.
    … …  
    153153MAUI is configured using the following variables :
    154154
    155  * `MAUI_SERVER_CONFIG` : nlist defining site-specific value for MAUI server base parameters. Keys are MAUI configuration parameters and value are parameter values. Defaults should be appropriate. Look at [source:templates/trunk/grid/glite-3.1/common/maui/server/config.tpl common/maui/server/config.tpl] for a list of supported parameters.
    156  * `MAUI_SERVER_POLICY` : nlist defining site-specific value for MAUI server scheduling policy parameters. Keys are MAUI configuration parameters and value are parameter values. Defaults should be appropriate. Look at [source:templates/trunk/grid/glite-3.1/common/maui/server/config.tpl common/maui/server/config.tpl] for a list of supported parameters.
     155 * `MAUI_SERVER_CONFIG` : nlist defining site-specific value for MAUI server base parameters. Keys are MAUI configuration parameters and values are parameter values. Defaults should be appropriate. Look at [source:templates/trunk/grid/glite-3.1/common/maui/server/config.tpl common/maui/server/config.tpl] for a list of supported parameters.
     156 * `MAUI_SERVER_POLICY` : nlist defining site-specific value for MAUI server scheduling policy parameters. Keys are MAUI configuration parameters and values are parameter values. Defaults should be appropriate. Look at [source:templates/trunk/grid/glite-3.1/common/maui/server/config.tpl common/maui/server/config.tpl] for a list of supported parameters.
    157157 * `MAUI_SERVER_RMCFG` : nlist defining site-specific value for MAUI server resource manager configuration parameters. Keys are MAUI configuration parameters and value are parameter values. Defaults should be appropriate. Look at [source:templates/trunk/grid/glite-3.1/common/maui/server/config.tpl common/maui/server/config.tpl] for a list of supported parameters.
    158158 * `MAUI_GROUP_PARAMS` : nlist defining group-specific parameters. Valid values are anything accepted by MAUI configuration directive `GROUPCFG`. Key is either a group (VO) name or `DEFAULT`. Default entry is applied to all groups (VOs) defined but without an explicit entry.
    … …  
    161161 * `MAUI_CLASS_PARAMS` : nlist defining class-specific parameters. Valid values are anything accepted by MAUI configuration directive `CLASSCFG`. Key is either a class name or `DEFAULT`. Default entry is applied to all classes defined but without an explicit entry.
    162162 * `MAUI_ACCOUNT_PARAMS` : nlist defining account-specific parameters. Valid values are anything accepted by MAUI configuration directive `ACCOUNTCFG`. Key must be a account name.
    163  * `MAUI_NODE_PARAMS` : nlist defining node-specific parameters. Keys must match worker node names or be `DEFAULT`. Values must be a nlist where keys are any valid keyworkds accepted by MAUI configuration directive `NODECFG` and values the value for the corresponding keyword.
     163 * `MAUI_NODE_PARAMS` : nlist defining node-specific parameters. Keys must match worker node names or be `DEFAULT`. Values must be a nlist where keys are any valid keywords accepted by MAUI configuration directive `NODECFG` and values the value for the corresponding keyword.
    164164 * `MAUI_STANDING_RESERVATION_ENABLED` : boolean value defining if creation of 1 standing reservation per node is enabled or not. Default : true. Note that use of this feature requires a proper setting of variable `WN_CPU_SLOT` (normally 2).
    165165 * `MAUI_STANDING_RESERVATION_CLASSES` : nlist defining classes which may access standing reservations. Key must be either a WN name or `DEFAULT`. Default entry is applied to all WNs without an explicit entry. Value must be a comma-separated list of classes.
    … …  
    194194This variable is `true` by default in QWG templates. Set it to `false` if you want to use the standard plugin.
    195195
    196 Another specific feature provided by QWG templates with respect to CE publishing into the BDII is the ability to run plugins in charge of updating CE dynamic information as a cron job on the LRMS host and to cache their outputs for later use by GIP itself. This is generally necessary in a multiple CE configuration and this is mandatory with MAUI-based plugins when using Torque/MAUI as MAUI commands can be executed only on the MAUI server. This ''cache mode'' is also lowering the polling rate on the batch system and protects again temporary failure of the LRMS to respond to the inquiry command (this is quite usual with MAUI when it is overloaded). To activiate this feature, you need to define the following variable in your [source:templates/trunk/sites/example/site/glite/config.tpl gLite parameters]:
     196Another specific feature provided by QWG templates with respect to CE publishing into the BDII is the ability to run plugins in charge of updating CE dynamic information as a cron job on the LRMS host and to cache their outputs for later use by GIP itself. This is generally necessary in a multiple CE configuration and this is mandatory with MAUI-based plugins when using Torque/MAUI as MAUI commands can be executed only on the MAUI server. This ''cache mode'' is also lowering the polling rate on the batch system and protects again temporary failure of the LRMS to respond to the inquiry command (this is quite usual with MAUI when it is overloaded). To activate this feature, you need to define the following variable in your [source:templates/trunk/sites/example/site/glite/config.tpl gLite parameters]:
    197197{{{
    198198variable GIP_CE_USE_CACHE ?= true;
    199199}}}
    200200
    201 This variable default depends on the number of CE configured. When there is only one CE, it is `false` for backward compatibility, else it is `true`. But it is recommended to set it to `true` inconditionally.
     201This variable default depends on the number of CE configured. When there is only one CE, it is `false` for backward compatibility, else it is `true`. But it is recommended to set it to `true` unconditionally.
    202202
    203203''Note: cache mode, even though it is essentially independent of the LRMS, is currently implemented only for MAUI. Defining this variable for unsupported LRMS has no effect.''
    … …  
    278278The main variable to enable profile cloning (currently supported only for gLite WN) is `USE_DUMMY`. It is `false` by default and must be set to `true` to enable profile cloning. This variable must be defined to `true` on all WNs, including the reference one (''exact node'').
    279279
    280 To use profile cloning, in additon to enable its use, you need to define a set of variables, generally in a common profile called by all WNs. This is generally done by creating a site-specific machine type for the WN (typically in `sites/xxx/machine-types/xxx/wn`, be sure not to overload standard `machine-types/wn`) that will do all the necessary initializations and include the standard `machine-types/wn`.
     280To use profile cloning, in addition to enable its use, you need to define a set of variables, generally in a common profile called by all WNs. This is generally done by creating a site-specific machine type for the WN (typically in `sites/xxx/machine-types/xxx/wn`, be sure not to overload standard `machine-types/wn`) that will do all the necessary initializations and include the standard `machine-types/wn`.
    281281
    282282The variables you need to define for profile cloning to work are:
    … …  
    464464It is sometimes desirable to drain a WMS. When draining a WMS doesn't accept any request to submit new jobs but continues to process already submitted jobs and accepts requests about job status or to cancel a job.
    465465
    466 With QWG, a WMS can be drain by defining in its profile the variable `WMS_DRAINED` to `true`. Undefining the variable reenable the WMS. Note that if you drain it manually and reconfigure the WMS with Quattor, it is re-enabled.
     466With QWG, a WMS can be drain by defining in its profile the variable `WMS_DRAINED` to `true`. Undefining the variable re-enables the WMS. Note that if you drain it manually and reconfigure the WMS with Quattor, it is re-enabled.
    467467
    468468=== WMS Client Configuration ===
    … …  
    580580__Base template__ : `machine-types/px`.
    581581
    582 MyProxy server configuration consists of defining policies for access to proxies stored on the server and their renewal. There are 2 sets of policiies : explicitly authorized policies and default policies. For each set a separate policy can be defined for:
     582MyProxy server configuration consists of defining policies for access to proxies stored on the server and their renewal. There are 2 sets of policies : explicitly authorized policies and default policies. For each set a separate policy can be defined for:
    583583 * renewers : list of clients able to renew a proxy. The variables to use are `MYPROXY_AUTHORIZED_RENEWERS` and `MYPROXY_DEFAULT_RENEWERS`.
    584584 * retrievers : list of clients able to retrieve a proxy it they have valid credentials and provide the same username/password as the one used at proxy creation. The variables to use are `MYPROXY_AUTHORIZED_RETRIEVERS` and `MYPROXY_DEFAULT_RETRIEVERS`.
    … …  
    598598
    599599VOMS server default configuration can be customized with the following variables:
    600  * `VOMS_VOS`: this variable describe each VO managed by the VOMS server. This is a nlist where the key is the VO name and the value a nlist specifiying the VO parameters. A typical entry is:
     600 * `VOMS_VOS`: this variable describes each VO managed by the VOMS server. This is a nlist where the key is the VO name and the value a nlist specifying the VO parameters. A typical entry is:
    601601{{{
    602602  'vo.lal.in2p3.fr',  nlist('port', '20000',