Tags:
, view all tags

The WMS configuration file

The behavior of most of the processes running on the WMS node is driven by parameters set in a common configuration file, usually /opt/glite/etc/glite_wms.conf. Currently the syntax is based on the ClassAd language. The parameter names are case insensitive.

The file contains multiple sections, one per service plus a common one:

[
    Common = [...];
    JobController = [...];
    LogMonitor = [...];
    NetworkServer = [...];
    WorkloadManager = [...];
    WorkloadManagerProxy = [...];
    WmsClient = [...];
    ICE = [...]
]

The value of a parameter can be expressed in terms of environment variables, with the typical UNIX shell syntax: a $ sign followed by the name of the variable in brackets (e.g. ${HOME}).

The following paragraphs describe the parameters available for each component. If a default value exists, this is shown in parenthesis at the end of the description.

Common configuration

LogFile
the name of the file where messages are logged
LogLevel
each logging statement in the code specifies a log level. If that level is less than or equal to LogLevel the message is actually logged, otherwise it is ignored. The levels go from 1 (minimum verbosity) to 6 (maximum verbosity)
DGUser
the user under which a WMS process runs

The parameters in the Common section may be overridden in the specific component sections. This usually happens with LogFile and LogLevel.

WorkloadManager configuration

The attributes available in this section, in alphabetical order, are:

BrokerLib
the library implementing the brokering functionality. What is specified here is loaded with dlopen(). ("libglite_wms_helper_broker_ism.so")
CeForwardParameters
the parameters forwarded by the WM to the CE
CeMonitorAsynchPort
the port used to listen to notification arriving from CEMon's. A value of -1 means that listening is disabled (-1)
CeMonitorServices
the list of CEMon's the WM listens to
DisablePurchasingFromGris
??? (false)
DispatcherType
the WM can read its input using different mechanisms. Currently supported types are "filelist" and "jobdir" ("filelist")
DliServiceName
??? ("data-location-interface")
EnableBulkMM
specifies if bulk matchmaking, i.e. matching multiple similar jobs in a collection in one shot, should be applied (false)
EnableIsmDump
specifies if a periodic dump of the ISM should be done. It also specifies if, at startup, the WM should read a dump produced during a previous run, if available (true)
EnablePurchasingFromRgma
purchase CE information from RGMA (false)
EnableRecovery
specifies if at startup the WM should perform a special recovery procedure for the requests that it finds already in its input. The recovery procedure is currently not reliable, so it should be disabled (false)
EnableStatusCheck
specifies if, for each request the WM reads from input, it should check the status of the request (e.g. for a submit the only acceptable status is WAITING). As for the recovery, this check is not very reliable, so it should be disabled (false)
ExpiryPeriod
the maximum time, expressed in seconds, a submitted job is kept in the overall system, from the time it arrives for the first time at the WM (86400, i.e. one day)
Input
the input source of new requests. If DispatcherType is "filelist" the source is a file; if DispatcherType is "jobdir" the source is the base dir of a JobDir structure, which is supposed to be already in place when the WM starts. A JobDir structure consists of a base dir under which lie other three subdirectories, named tmp, new, old ("${EDG_WL_TMP}/workload_manager/input.fl")
IsmBlackList
a list of CEs that have to be excluded in the ISM
IsmCEMonAsynchPurchasingRate
??? (30)
IsmCEMonPurchasingRate
??? (120)
IsmDump
if the ISM dump is enabled, the dump, in ClassAd format, will be written to this file. In order to avoid file corruptions, the contents of a dump are built in a temporary file, whose name is the same value of this parameter with the prefix ".tmp|, which only at the end of the operation is renamed to the specified file ("${GLITE_WMS_TMP}/workload_manager/ismdump.fl" - but it's not in filelist format!)
IsmDumpRate
the period between two ISM dumps, in seconds. The default value is way too short (50)
IsmIiPurchasingRate
the period between two ISM purchases from the BDII, in seconds (240)
IsmRgmaPurchasingRate
the period between two ISM purchases from RGMA, in seconds (120)
IsmUpdateRate
the period between two updates of the ISM, in seconds. Note that conceptually purchasing just retrieves the list of available resources, wheres an ISM update gathers the resource information for each resource. The default value is too short (50)
JobWrapperTemplateDir
the job wrapper sent to the CE and then executed on Worker Node is based on a bash template which is augmented by the WM with job-specific information. This is the location where all the templates - one at the moment - are stored ("${GLITE_WMS_LOCATION}/etc/templates")
LogFile
the name of the file where messages are logged
LogLevel
each logging statement in the code specifies a log level. If that level is less than or equal to LogLevel the message is actually logged, otherwise it is ignored. The levels go from 1 (minimum verbosity) to 6 (maximum verbosity)
MatchRetryPeriod
once a job becomes pending, meaning that there are no resources available, this parameter represents the period between successive match-making attempts, in seconds (1000)
MaxOutputSandboxSize
the maximum size of the output sandbox, in bytes. The limit is currently enforced by the job wrapper running on the Worker Node, which doesn't upload more data than what specified here. If the value is -1 there is no limit. Currently the mechanism doesn't work well, so it is suggested to set this parameter to -1 (100000000)
MaxRetryCount
the system limit to the number of deep resubmissions for a job. The actual limit is the minimum between this value and the one specified in the job description (10)
MaxShallowRetryCount
the system limit to the number of shallow resubmissions for a job. The actual limit is the minimum between this value and the one specified in the job description (10)
PboxHostName
the host where a G-PBox service runs
PboxPortNum
the port on PboxHostName where the G-PBox service listens (6699)
PboxSafeMode
??? (false)
PipeDepth
the WM internally is structured with one dispatcher thread and one or more request handlers, communicating through a bounded queue. This parameter specifies the upper bound to the size of that queue (10)
RgmaConsumerLifeCycle
??? (30)
RgmaConsumerTtl
??? (300)
RgmaQueryTimeout
??? (30)
SiServiceName
??? ("org.glite.SEIndex")
TokenFile
the shallow resubmission mechanism works by removing an empty file on the gridftp server running on the WSM machine from the job wrapper running on a Worker Node. This parameter specifies the name of that file ("token.txt")
WorkerThreads
the number of request handler threads (10)

JobController configuration

LogMonitor configuration

NetworkServer configuration

WorkloadManagerProxy configuration

WmsClient configuration

ICE configuration

-- FrancescoGiacomini - 29 Oct 2007

Edit | Attach | PDF | History: r15 | r4 < r3 < r2 < r1 | Backlinks | Raw View | More topic actions...
Topic revision: r2 - 2007-10-29 - FrancescoGiacomini
 
  • Edit
  • Attach
This site is powered by the TWiki collaboration platformCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback