# # GVDS 1.1.0 sample property file # # This file will report the majority of the settable properties, and # their respective default values. Please refer to the user guide for # a more in-depth discussion of the configuration options. # # Some properties rely with their default on the value of other # properties. As a notation, the curly braces refer to the value of the # named property. For instance, ${vds.home} means that the value depends # on the value of the vds.home property plus any noted additions. You # can use this notation to refer to other properties, though the extend # of the subsitutions are limited. Usually, you want to refer to a set # of the standard system properties. Nesting is not allowed. # Substitutions will only be done once. # # SECTION "BASICS" # # Property : vds.home # Systems : all # Type : directory location string # Default : ""$VDS_HOME"" # # The property vds.home cannot be set in the property file. Any of the # shell wrapper script for the applications will set this property from # the value of the environment variable $VDS_HOME. # # vds.home ""$VDS_HOME"" # # SECTION "DIRECTORY LOCATION PROPERTIES" # # Property : vds.properties # Systems : all # Type : file location string # Default : ${vds.home}/etc/properties # # The system-wide properties file will be looked for in its default # place. It will usually reside in $VDS_HOME/etc as file named # properties. # # vds.properties ${vds.home}/etc/properties # Property : vds.user.properties # Systems : all # Type : file location string # Default : ${user.home}/.chimerarc # # Each user can overwrite the system-wide properties with his or her own # definitions. The user properties rely on the system's notion of the # user home directory, as reflected in the JRE system properties. In the # user's home directory, a file .chimerarc will be taken to contain user # property definitions. Note that ${user.home} is a system property. # # vds.user.properties ${user.home}/.chimerarc # Property : vds.home.datadir # Systems : all # Type : directory location string # Default : ${vds.home}/share # # The datadir directory contains broadly visiable and possilby exported # configuration files that rarely change. This directory is currently # unused. # # vds.home.datadir ${vds.home}/share # Property : vds.home.sysconfdir # Systems : all # Type : directory location string # Default : ${vds.home}/etc # # The system configuration directory contains configuration files that # are specific to the machine or installation, and that rarely change. # This is the directory where the XML schema definition copies are # stored, and where the base pool configuration file is stored. # # [NOTE to Gaurang: the dyanmic poolcfg xml file should be in localstate] # # vds.home.sysconfdir ${vds.home}/etc # Property : vds.home.localstatedir # Systems : all # Type : directory location string # Default : ${vds.home}/com # # Frequently changing files that are broadly visible are stored in the # shared state directory. This is currently unused. # # vds.home.sharedstatedir ${vds.home}/com # Property : vds.home.localstatedir # Systems : all # Type : directory location string # Default : ${vds.home}/var # # Frequently changing files that are specific to a machine and/or # installation are stored in the local state directory. This directory # is being used for the textual transformation catalog, file-based VDCs, # and the file-based replica catalog of the shell planner. # vds.home.localstatedir ${vds.home}/var # # SECTION "SIMPLE FILE LOCATION PROPERTIES" # # Property : vds.schema.vdl # Systems : Chimera, VDC # Type : XML schema file location string # Default : ${vds.home.sysconfdir}/vds-1.21.xsd # # This file is a copy of the XML schema that describes VDLx files. VDLx # files and fragments are used in various places throughout the abstract # planning process. Providing a copy of the schema enables the parser to # use the local copy instead of reaching out to the internet, and # obtaining the latest version from the GriPhyN website dynamically. # # vds.schema.vdl ${vds.home.sysconfdir}/vds-1.21.xsd # Property : vds.schema.dax # Systems : all # Type : XML schema file location string # Value[0] : ${vds.home.sysconfdir}/dax-1.5.xsd # Value[1] : ${vds.home.sysconfdir}/dax-1.6.xsd # Value[2] : ${vds.home.sysconfdir}/dax-1.7.xsd # Default : ${vds.home.sysconfdir}/dax-1.7.xsd # # This file is a copy of the XML schema that describes abstract DAG # files that are the result of the abstract planning process, and input # into any concrete planning. Providing a copy of the schema enables the # parser to use the local copy instead of reaching out to the internet, # and obtaining the latest version from the GriPhyN website dynamically. # # vds.schema.dax ${vds.home.sysconfdir}/dax-1.7.xsd # Property : vds.schema.ivr # Systems : all # Type : XML schema file location string # Default : ${vds.home.sysconfdir}/iv-1.2.xsd # # This file is a copy of the XML schema that describes invocation record # files that are the result of the a grid launch in a remote or local # site. Providing a copy of the schema enables the parser to use the # local copy instead of reaching out to the internet, and obtaining the # latest version from the GriPhyN website dynamically. # # vds.schema.ivr ${vds.home.sysconfdir}/iv-1.2.xsd # Property : vds.db.pool # Moved to : vds.pool.file # # This property name was deprecated, and will eventually be phased out. # Please use the new name in the future. # # vds.db.pool ${vds.home.sysconfdir}/pool.config # Property : vds.db.tc # Moved to : vds.tc.file # # This property name was deprecated, and will eventually be phased out. # Please use the new name in the future. # # vds.db.tc ${vds.home.localstatedir}/tc.data # Property : vds.pool.file # Systems : Pegasus # Type : file location string # Default : ${vds.home.sysconfdir}/pool.config # Old name : vds.db.pool # See also : vds.pool.mode # # Running things on the grid requires an extensive description of the # capabilities of each compute cluster, commonly termed "pool". This # property describes the location of the file that contains such a pool # description. As the format is currently in flow, please refer to the # userguide and Pegasus for details which format is expected. # # vds.pool.file ${vds.home.sysconfdir}/pool.config vds.pool.file=/home/gmehta/VDS/config/pool.config.xml # Property : vds.tc.file # Systems : all # Type : file location string # Default : ${vds.home.localstatedir}/tc.data # Old name : vds.db.tc # See also : vds.tc.mode # # The transformation catalog is a 3+ column textual file that describes # in a simple column based format the mapping from a logical # transformation for each pool to the physical application, and optional # environment settings. All concrete planners use this repository to map # the lTR from the abstract DAX into an application invocation. Refer to # the user guide for details. # # vds.tc.file ${vds.home.localstatedir}/tc.data vds.tc.file=/home/gmehta/VDS/config/tc.data # Property : vds.db.rc # System : Chimera shell planner # Type : file-based RC file location string # Default : ${vds.home.localstatedir}/rc.data # # The shell planner that comes with Chimera completely by-passes any # replica management catalogs that come with Pegasus. The shell planner # uses a simple three column textual file to store the mapping of LFNs # to PFNs and pools. # # vds.db.rc ${vds.home.localstatedir}/rc.data # # SECTION "CHIMERA VDC ACCESS" # # Property : vds.db.vdc.schema # System : Chimera VDC # Type : Java class name # Value[0] : SingleFileSchema # Value[1] : ChunkSchema # Default : org.griphyn.vdl.dbschema.SingleFileSchema # See also : vds.db.driver # # This property denotes the schema that is being used to access a VDC. # The VDC is a multi-layer architecture, with the dbschema sitting on # top of the dbdrivers. Some schemas, like the default schema, do not # access the driver level at all. # # Currently available are only SingleFileSchema and ChunkSchema. These # are names of Java classes. If no absolute Java classname is given, # "org.griphyn.vdl.dbschema." is prepended. Thus, by deriving from the # DatabaseSchema API, and implementing the VDC interface, users can # provide their own classes here. Anything further properties in # "vds.db.vdc.schema.*" will be copied into the schema properties, and # thus made available to the schema. # # vds.db.vdc.schema SingleFileSchema vds.db.vdc.schema=ChunkSchema # Property : vds.db.vdc.schema.xml.url # System : Chimera VDC, SingleFileSchema, ChunkSchema # Type : VDLx XML Schema location # Default : ${vds.schema.vdl} # # Various schemas manipulate VDLx internally, and need the knowledge of # the schemas location to construct their parsers. This schema property # enables users to provide backward compatible parsers for VDC data # independent of the new data being read from files. # # vds.db.vdc.schema.xml.url ${vds.schema.vdl} # Property : vds.db.vdc.schema.file.store # System : Chimera VDC, SingleFileSchema # Type : file location string # Default : ${vds.home.localstatedir}/vdc.db # # The VDC can be stored in a single file, which is the default mode of # operation. This property determines the basename of the file. # Extensions allow for a degree of rollbacks. # # vds.db.vdc.schema.file.store ${vds.home.localstatedir}/vdc.db # Property : vds.db.ptc.schema # System : Chimera Provenance Tracking Catalog (PTC) # Type : Java class name # Value : InvocationSchema # Default : (no default) # See also : vds.db.driver # # This property denotes the schema that is being used to access a PTC. # The PTC is usually not a standard installation. If you use a database # backend, you most likely have a schema that supports PTCs. By default, # no PTC will be used. # # Currently available is only InvocationSchema, if you want to store # provenance tracking records. Beware, this can become a lot of data. # The values are names of Java classes. If no absolute Java classname # is given, "org.griphyn.vdl.dbschema." is prepended. Thus, by deriving # from the DatabaseSchema API, and implementing the PTC interface, # users can provide their own classes here. Anything further properties # in "vds.db.ptc.schema.*" will be copied into the schema properties, # and thus made available to the schema. # # vds.db.ptc.schema (no default) #vds.db.ptc.schema=InvocationSchema # Property : vds.db.driver # System : Chimera VDC # Type : Java class name # Value[0] : Postgres # Value[1] : MySQL # Value[2] : SQLServer2000 (not yet implemented!) # Value[3] : Oracle (not yet implemented!) # Default : (no default) # See also : vds.db.schema # # The database driver class is dynamically loaded, as required by the # schema. Currently, only PostGreSQL 7.3 and MySQL 4.0 are supported. # Their respective JDBC3 driver is provided as part and parcel of the # GVDS. # # A user may provide their own implementation, derived from # org.griphyn.vdl.dbdriver.DatabaseDriver, to talk to a database of # their choice. # # vds.db.driver (no default) vds.db.driver=MySQL #vds.db.driver=MySQL # Property : vds.db.driver.url # System : Chimera VDC # Type : JDBC database URI string # Default : (no default) # Example : jdbc:postgresql:${user.name} # # Each database has its own string to contact the database on a given # host, port, and database. Although most driver URLs allow to pass # arbitrary arguments, please use the vds.db.driver.* keys to preload # these arguments. THIS IS A MANDATORY PROPERTY FOR ANY DBMS BACKEND. # # Postgres : jdbc:postgresql:[//[:]/] # MySQL : jdbc:mysql://[[:]]/ # SQLServer: jdbc:microsoft:sqlserver://: # Oracle : jdbc:oracle:thin:[/]@//[:]/ # # vds.db.driver.url (no default) #vds.db.driver.url=jdbc:postgresql://smarty.isi.edu:11111/vdc vds.db.driver.url=jdbc:mysql://smarty.isi.edu:3306/vdc # Property : vds.db.driver.user # System : Chimera VDC # Type : string # Default : (no default) # Example : ${user.name} # # In order to access a database, you must provide the name of your # account on the DBMS. This property is database-independent. THIS IS A # MANDATORY PROPERTY FOR MANY DBMS BACKENDS. # # vds.db.driver.user (no default) vds.db.*.driver.user=dbuser # Property : vds.db.driver.password # System : Chimera VDC # Type : string # Default : (no default) # Example : ${user.name} # # In order to access a database, you must provide an optional password # of your account on the DBMS. This property is database-independent. # THIS IS A MANDATORY PROPERTY, IF YOUR DBMS BACKEND ACCOUNT REQUIRES # A PASSWORD. # # vds.db.driver.password (no default) vds.db.*.driver.password=mamamia # Property : vds.db.driver.* # System : Chimera VDC # # Each database has a multitude of options to control in fine detail # the further behaviour. You may want to check the JDBC3 documentation # of the JDBC driver for your database for details. The keys will be # passed as part of the connect properties by stripping the # "vds.db.driver." prefix from them. # # Postgres 7.3 parses the following properties: # # vds.db.driver.user # vds.db.driver.password # vds.db.driver.PGHOST # vds.db.driver.PGPORT # vds.db.driver.charSet # vds.db.driver.compatible # # MySQL 4.0 parses the following properties: # # vds.db.driver.user # vds.db.driver.password # vds.db.driver.databaseName # vds.db.driver.serverName # vds.db.driver.portNumber # vds.db.driver.socketFactory # vds.db.driver.strictUpdates # vds.db.driver.ignoreNonTxTables # vds.db.driver.secondsBeforeRetryMaster # vds.db.driver.queriesBeforeRetryMaster # vds.db.driver.allowLoadLocalInfile # vds.db.driver.continueBatchOnError # vds.db.driver.pedantic # vds.db.driver.useStreamLengthsInPrepStmts # vds.db.driver.useTimezone # vds.db.driver.relaxAutoCommit # vds.db.driver.paranoid # vds.db.driver.autoReconnect # vds.db.driver.capitalizeTypeNames # vds.db.driver.ultraDevHack # vds.db.driver.strictFloatingPoint # vds.db.driver.useSSL # vds.db.driver.useCompression # vds.db.driver.socketTimeout # vds.db.driver.maxReconnects # vds.db.driver.initialTimeout # vds.db.driver.maxRows # vds.db.driver.useHostsInPrivileges # vds.db.driver.interactiveClient # vds.db.driver.useUnicode # vds.db.driver.characterEncoding # # MS SQL Server 2000 support the following properties (keys are # case-insensitive, e.g. both "user" and "User" are valid): # # vds.db.driver.User # vds.db.driver.Password # vds.db.driver.DatabaseName # vds.db.driver.ServerName # vds.db.driver.HostProcess # vds.db.driver.NetAddress # vds.db.driver.PortNumber # vds.db.driver.ProgramName # vds.db.driver.SendStringParametersAsUnicode # vds.db.driver.SelectMethod # # SECTION "PEGASUS REPLICA MANAGEMENT PROPERTIES" # # Property : vds.replica.mode # System : Pegasus # Type : enumeration # Value[0] : rc # Value[1] : rls # Default : rc # # The replica mode controls which replica management mechanism is being # employed by Pegasus. The possible values are "rc" and "rls". By # default, the G2RC replica catalog is being accessed. The new RLS is # highly recommended, though, and will become the default eventually. # # vds.replica.mode rc vds.replica.mode=rls # Property : vds.rls.url # System : Pegasus, RLS # Type : URI string # Default : (no default) # # When using the modern RLS replica catalog, the URI to the RLI must be # provided to Pegasus to enable it to look up filenames. There is no # default. # # vds.rls.url (no default) vds.rls.url=rls://dataserver.phys.uwm.edu # Property : vds.rls.query # System : Pegasus, RLS # Type : enumeration # Value[0] : bulk # Value[1] : multiple # Default : bulk # # The RLS server offers significant performance improvement when being # bulk queried for filenames. Alas, bulk operations are only available # starting with version 2.0.5 of the RLS software. The possible values # for this key are "bulk" and "multiple". With the current RLS version # being 2.0.7, "bulk" is the default. For backward compatibility, you # can use "multiple". # # vds.rls.query bulk # Property : vds.rls.query.attrib # System : Pegasus, RLS # Type : boolean # Value[0] : true # Value[1] : false # Default : false # # The RLS server offers significant performance improvement when being # bulk queried for filenames. Alas, bulk attribute operations are only available # starting with version 2.0.9 of the RLS software. The possible values # for this key are "true" and "false". The pool attrib lookup is turned "off" by # default. The bulk rls attrib capablity should be available soon. If attrib lookup # is enabled the time generation for a plan greatly increases but will provide a better plan. # # vds.rls.query.attrib false vds.rls.query.attrib=true # Property : vds.rc.host # System : Pegasus, G2RC # Type : string # Default : (no default) # # If using the G2RC replica catalog, the host URL to the LDAP server # must be provided. There is no default. # # vds.rc.host (no default) # Property : vds.rc.collection # System : Pegasus, G2RC # Type : string # Default : GriphynData # # The Pegasus concrete planner registers all the materialized data in # one logical collection which is specified by this property. By default # it is GriphynData. # # vds.rc.collection GriphynData # Property : vds.rc.manager_dn # System : Pegasus, G2RC # Type : X.400 string # Default : (no default) # # In order to manage the catalog itself, e.g. instantiate collections # and locations, the management DN must be provided to various # Pegasus-related tools, including gencdag. There is no default. # # vds.rc.manager_dn (no default) # Property : vds.rc.password # System : Pegasus, G2RC # Type : string # Default : (no default) # # If you connect to the replica catalog, a password must be specified to # authenticate the requested actions. There is no default. # # vds.rc.password (no default) # # SECTION "PEGASUS IN ACTION" # # Property : vds.pool.mode # System : Pegasus, MDS, PoolConfig # Type : enumeration # Value[0] : single # Value[1] : multiple # Value[2] : xml # Default : single # # The pool.config file is available in two flavors: # # 1) The old textual format employs multiple columns in a textual file, # see sample.pool.config.old. This format is DEPRECATED and will be # removed in the mid-term future. The odl textual format is available # in two parsing modes for scalability purposes: # # a) The "single" modes reads the old format pool.config file once and # only once. The data is kept in memory for better performance. We # recommend this mode for pool files with less than 1k lines. # b) The "multiple" mode reads of the old format pool.config file # every time it needs to look up somethings. Use this mode if you # have memory problems, or if you have an unusually huge pool.config # file. # # 2) The "xml" format is an XML-based file. It is generated using the # genpoolconfig client application program that is shipped with # Pegasus. The XML input file for Pegasus can be generated in various # ways, that can be used exclusively or combined at your option: # # a) The pool configuration file can be generated using information # that is published in MDS (see VDS user guide document). This is # the recommended way. # # b) It can also be published by converting the new, easier to # read and modify local multiline pool config file. An example # is provided in sample.pool.config.new. Use this option if you # have no network connectivity, or for tests. # # vds.pool.mode single vds.pool.mode=xml # Property : vds.tc.mode # System : Pegasus, TC # Type : enumeration # Value[0] : single # Value[1] : multiple # Default : single # See also : vds.db.tc # # The Transformation Catalog (TC) is currently a three-column file. # Similar to the pool configuration, for speed and memory consumption, # two parse modes are avaialable: # # 1) In "single" mode, the file is read once and cached in main memory. # This yields a good performance while consuming some memory. We # recommend to use this methods for files with less than 10000 # entries. # # 2) In "multiple" mode, the file is searched for item as required, # incurring multiple reads. While slowing down the overall # performance, it is memory conservative. # # Future modifications to the TC may extend the enumeration. # # vds.tc.mode single vds.tc.mode=File # Property : vds.transfer.mode # System : Pegasus # Type : enumeration # Value[0] : single # Value[1] : multiple # Default : single # # Each job usually has data products that are required to be staged out # to a final resting place, or staged to another job running at a # different pool. The transfer mode determines the number of transfer # jobs added to a compute job: # # 1) In "single" mode each file that needs to be transferred will # generate one transfer job. This mode works well with kickstart, # and employs globus-url-copy as transfer agent. It uses two party # transfers based on the assumption that the gridftp server runs # on the gatekeeper. # # 2) In "multiple" mode, all files will be attempted to be transferred # with just one transfer job, resulting in multiple transfers. This # mode uses the provided appliation "transfer" that internally # invoked globus-url-copy to transfer each file. "transfer" may not # agree with "kickstart", though this is to be fixed. Files are # transferred sequentially, one after the other. # # Pegasus is researching a new transfer job that will enable multiple # transfers in parallel. Further properties will allow the # parallelization to be tuned. # # vds.transfer.mode single vds.transfer.mode=multiple # Property : vds.transfer.throttle.processes # System : Pegasus # Type : integer # Default : 4 # see also : vds.transfer.mode,vds.transfer.throttle.streams # # This property is picked up when transfer mode (vds.transfer.mode) is # multiple. In this mode, multiple files are transferred using a # transfer executable that comes with the VDS system. This transfer # executable attempts to transfer multiple files by spawning multiple # g-u-c processes. By default a maximum of 4 processes are spawned # to transfer the files. Using this one can change the number of # processes that are spawned by the transfer executable. # # vds.transfer.throttle.processes 4 vds.transfer.throttle.processes=2 # Property : vds.transfer.throttle.streams # System : Pegasus # Type : integer # Default : 1 # see also : vds.transfer.mode,vds.transfer.throttle.processes # # Whatever the transfer mode specified, at present each uses # globus-url-copy(g-u-c) as the underlying transfer mechanism. # g-u-c can open multiple streams to do the ftp data transfer. # This property can be used to set the number of streams that # are used to transfer one file by underlying g-u-c. # It directly maps to the -p option of g-u-c. # # vds.transfer.throttle.streams 1 #vds.transfer.throttle.streams=2 # Property : vds.exitcode.mode # System : Pegasus # Type : enumeration # Value[0] : all # Value[1] : none # Value[2] : essential # Default : none # # Jobs that are "kickstarted" by a grid launcher report back information # about the execution, resource consumption, and - most importantly - # the exit code of the remote application. Armed with this knowledge, it # is possible to have DAGMan stop the workflow and create a rescue # workflow on remote execution errors. In "all" mode, each kickstarted # job's invocation record will be parsed by a DAGMan postscript. In # "none" mode, the default, remote failures will not abort the DAG. In # "essential" mode, only certain classes of remote jobs get the ability # to abort the workflow, while other, non-essential, classes of jobs will # not have their invocation record abort the workflow. # # vds.exitcode.mode none vds.exitcode.mode=all # Property : vds.dir.exec # System : Pegasus # Type : remote directory location string # Default : (no default) # # This property modifies the remote location work directory in which all # your jobs will run. If the path is relative then it is appended to the # exec mount point (old pool configuration) or work directory (new pool # configuration), as specified in the pool config file. If the path is # absolute then it overrides the mount point specified in the pool # config file. # # vds.dir.exec (no default) vds.dir.exec=EXECDIR # Property : vds.dir.storage # System : Pegasus # Type : remote directory location string # Default : (no default) # # This property modifies the remote storage location on various pools. # If the path is relative then it is appended to the storage mount point # specified in the pool.config file. If the path is absolute then it # overrides the storage mount point specified in the pool config file. # # vds.dir.storage (no default) vds.dir.storage=DATADIR # Property : vds.lsf.projects # Moved to : vds.scheduler.remote.queues # # This property name was deprecated, and will eventually be phased out. # Please use the new name in the future. # # vds.lsf.projects (no default) # Property : vds.scheduler.remote.projects # System : Pegasus # Type : list of kv pairs # Default : (no default) # Example : jazz=PDQ,pnnl=emsl12491 # # This property allows to set the *project* name that is to be used for # each pool. Usually, such project names are specific to a small set of # users, and can not be well set in the pool configuration file. Please # note that the key is the pool handle, and the value is the project # name. Setting the project will result in the generation of an RSL # term (project=xxxx) for the matching pool handle. # # vds.scheduler.remote.projects (no default) # Property : vds.scheduler.remote.queues # System : Pegasus # Type : list of kv pairs # Default : (no default) # Example : jazz=PDQ,pnnl=emsl12491 # # This property allows to set the *queue* name that is to be used for # each pool. Usually, such queue names are specific to single users, # and can thus not be well set in the pool configuration file. Please # note that the key is the pool handle, and the value is the queue name. # The property is applicable to any remote scheduling system that # employs named queues, e.g. PBS or LSF. Setting the queue will result # in the generation of an RSL clause (queue=xxxx) for the matching pool # handle. # # vds.scheduler.remote.queues (no default) # Property : vds.scheduler.remote.maxwalltimes # System : Pegasus # Type : list of kv pairs # Default : (no default) # Example : jazz=10,pnnl=20 # # This property allows to set the *walltime* for your jobs on each # pool. Max Walltime means the maximum amount of time a job would run # for on a pool. This property is applicable to any remote scheduling # system that employs walltimes like PBS. Setting the walltime will # result in the generation of an RSL clause (maxwalltime=xxxx) for the # matching pool handle. Please note that most if all scheduling # systems that use this kill the job if the jobs running time # exceed the advertised walltime in the job description. # # vds.scheduler.remote.maxwalltimes (no default) # Property : vds.pegasus.kickstart-condor # Moved to : vds.scheduler.condor.start # # This property name was deprecated, and will eventually be phased out. # Please use the new name in the future. # # vds.pegasus.kickstart-condor (no default) # Property : vds.pegasus.condor-bin # Moved to : vds.scheduler.condor.bin # # This property name was deprecated, and will eventually be phased out. # Please use the new name in the future. # # vds.pegasus.condor-bin (no default) # Property : vds.pegasus.condor-config # Moved to : vds.scheduler.condor.config # # This property name was deprecated, and will eventually be phased out. # Please use the new name in the future. # # vds.pegasus.condor-config (no default) # Property : vds.scheduler.condor.start # System : Pegasus, DAG auto-submit # Type : local file location string # Default : (no default) # Old name : vds.pegasus.kickstart-condor # See also : vds.scheduler.condor.bin, vds.scheduler.condor.config # # This property needs to be set if you intend to submit jobs to Condor # from Pegasus itself instead of stopping after all Condor files are # generated. Starting a generated workflow requires to activate # condor_submit_dag in the DAG directory. An implementation for the # auto-submittor for this option is provided in # ${vds.home}/bin/kickstart-condor # # vds.scheduler.condor.start (no default) # Property : vds.scheduler.condor.bin # System : Pegasus, DAG auto-submit # Type : local directory location string # Default : (no default) # Old name : vds.pegasus.condor-bin # See also : vds.scheduler.condor.start, vds.scheduler.condor.config # # This property needs to be set if you intend to submit jobs to Condor # from Pegasus itself instead of stopping after all Condor files are # generated. This property points to the location of the "bin" directory # of your local Condor installation. # # vds.scheduler.condor.bin (no default) # Property : vds.scheduler.condor.config # System : Pegasus # Type : local file location string # Default : (no default) # Old name : vds.pegasus.condor-config # See also : vds.scheduler.condor.start, vds.scheduler.condor.bin # # This property needs to be set if you intend to submit jobs to Condor # from Pegasus itself instead of stopping after all Condor files are # generated. This property points to the location where the # condor_config file is stored. Refer to the Condor manual for the # default locations of the Condor system. # # vds.scheduler.condor.config (no default) # Property : vds.scheduler.condor.release # System : Pegasus # Type : non-negative integer # Default : 3 # # This property determines the number of release attempts that are # written into the submit file. Condor will hold jobs on certain kinds # of failures. Many known failing conditions are transient, thus, if # the job is automatically release after a short time, it usually # progresses. # # vds.scheduler.condor.release 3 # Property : vds.scheduler.condor.output.stream # System : Pegasus # Type : Boolean # Value[0] : false # Value[1] : true # Default : true # See also : vds.scheduler.condor.error.stream # # By default, GASS streams back stdout continuously. In this default # mode, it will require additional filedescriptors on the gatekeeper. # Recent versions of Globus and Condor allow the content of stdout to be # streamed back after the job is done. While no content is visible # during the execution of the job, it saves precious gatekeeper # resources. # # vds.scheduler.condor.output.stream false # Property : vds.scheduler.condor.error.stream # System : Pegasus # Type : Boolean # Value[0] : false # Value[1] : true # Default : true # See also : vds.scheduler.condor.output.stream # # By default, GASS streams back stderr continuously. In this default # mode, it will require additional filedescriptors on the gatekeeper. # Recent versions of Globus and Condor allow the content of stderr to be # streamed back after the job is done. While no content is visible # during the execution of the job, it saves precious gatekeeper # resources. # #vds.scheduler.condor.error.stream false # Property : vds.giis.host # System : Pegasus # Type : string # Default : (no default) # See also : vds.pool.mode # # This property needs to be set if you set the vds.pool.mode to xml and you # wish to obtain the pool config information dynamically using MDS along # with or without local pool config support files. The property needs to # be set to the hostname and optional port of the GIIS service that is # aggregating pool information, e.g. smarty.isi.edu:2135 # # vds.giis.host (no default) #vds.giis.host = sukhna.isi.edu:2135 # Property : vds.giis.dn # System : Pegasus # Type : X.400 string # Default : (no default) # See also : vds.pool.mode # # If the vds.giis.host is set, and MDS is used to obtain the pool # configuration, the 'distinguished name' to contact the GIIS needs # to be specified with this property, e.g. "MDS-vo-name=GRIPHYN,o=Grid" # # vds.giis.dn (no default) #vds.giis.dn = mds-vo-name=SC,o=grid # Property : vds.log4j.log # System : Pegasus, LoggerService, Log4j # Type : filename # Default : (no default) # See also : vds.loggerservice.url # # If you plan to log the interal RLS queries in Pegasus to a local file # using log4j then set the property to the location of the file you want # the log written to. THIS IS AN EXPERIMENTAL FEATURE. # # vds.log4j.log (no default) # Property : vds.loggerservice.url # System : Pegasus, Ogsa LoggerService # Type : URI string # Default : (no default) # See also : vds.log4j.log # # If you plan to log internal RLS queries in pegasus to an OGSA logger # service. Set the property to the url of the logger service. THIS IS AN # EXPERIMENTAL FEATURE. # # vds.loggerservice.url (no default) # # SECTION "CHIMERA IN ACTION" # # Property : vds.log.* # System : Chimera # Type : filename or stdio handle # Default : (no default) # Example : vds.log.chunk=stderr # # The Chimera system has (currently, about to change) a logging system # that works with queues and levels. Each logging Q can be addressed # separately, and given either a filename to append log information # onto, "stdout" for standard output, or "stderr" for standard error. # You may use the same filename for different queues. # # vds.log.* (no default) # Property : vds.verbose # System : Chimera # Type : flag # Default : (not specified) # # If the verbose option is specified, the Chimera system will provide # maximum logging on all queues. This is very verbose, but sometimes # the easiest way to track an error. vds.transfer.mode.links=true vds.transfer.force=true vds.db.tc.driver=MySQL vds.db.tc.driver.url=jdbc:mysql://smarty.isi.edu:3306/txcatalog vds.db.vdc.driver=MySQL vds.db.vdc.driver.url=jdbc:mysql://smarty.isi.edu:3306/vdc #vds.verbose=2 vds.db.ptc.driver=MySQL vds.db.ptc.driver.url=jdbc:mysql://gaul.isi.edu:3306/ptc vds.db.ptc.schema=InvocationSchema vds.db.ptc.driver.user=mcs vds.db.ptc.driver.password=mcsuser vds.dir.create.mode=Tentacles vds.rls.exit=never