Page History
- 2013-Nov-19 15:33 adesmet
- 2013-Nov-19 15:27 adesmet
- 2013-Nov-19 15:26 adesmet
- 2013-Nov-19 15:23 adesmet
- 2013-Nov-19 15:01 adesmet
- 2013-Nov-19 15:00 adesmet
- 2012-Nov-13 15:12 adesmet
- 2012-Oct-11 18:48 adesmet
- 2011-Jul-11 17:13 adesmet
- 2009-Aug-24 15:46 psilord
- 2009-Aug-10 16:08 psilord
- 2009-Aug-10 16:01 psilord
- 2009-Aug-10 16:00 psilord
Adding Configuration File Parameters to HTCondor
The method by which condor_configurations file parameters are to be added into HTCondor has changed.
There is a file called src/condor_c++_util/param_info.in
and in it are definitions like this:
[SCHEDD] aliases= default=$(SBIN)/condor_schedd version=0.0.0 range=.* state=default type=string is_macro=false reconfig=true customization=seldom friendly_name=Schedd usage=Where are the binaries for these daemons? url=http://research.cs.wisc.edu/htcondor/manual/current/3_3Configuration.html tags=master,master id=552
It is strongly recommended to copy the above and use it as a template.
Required fields
The parameter name in square brackets marks the beginning of an entry.
- type - The type. Valid values are: bool, double, int, long, path, string
Strongly recommended fields
The attributes that you really need to care about are default, type, usage, friendly_name, url, and tags.
- default - The default value. (ex. $(SBIN)/condor_master, 10, false)
- friendly_name - A more human friendly version of the parameter name. May just be the parameter name with underscores changed to spaces and in mixed case. (ex. Filesystem Domain)
- usage - Brief information on how to set the paramter. (ex. to specify that each machine has its own file system, Log files) (The current entries are wildly inconsistent.
- url - Link to the matching documentation in the manual. You can leave this as the default pointing to the general configuration section.
- tags - Comma separated (NO SPACES) list of tags to identify the setting. If the setting is only relevant for a particular program or daemon, list that daemon here, minus any condor_ prefix (ex. schedd, submit).
- customization - How often is it changed by users? seldom, often, or always. Also "const", for things which should never be changed (HOUR, MINUTE). One setting uses "NORMAL", no idea.
- reconfig - true or false. If true, the value can be changed with condor_reconfig; otherwise it will only be respected on daemon restart. (TODO: check)
Optional fields
- range - for type=int and type=double is a pair of comma separated values indicating the minimum and maximum allowed values. You can omit the second number to indicate INT_MAX or DBL_MAX respectively. (ex range=.*; range=1024,; range=1,1000000000) (<- TODO ".*" suggests regular expressions are allowed?)
- aliases - List(?) of other parameter names which are essentially identical to this use, generally used for backward compatibility. (ex aliases=GROUP_DYNAMIC_MACH_CONSTRAINT)
- id - Unused? (TODO check) Just copy it from the template for now.
- state - TODO No idea. Exclusively used as "state=default" for now.
- is_macro - TODO No idea. overwhelmingly is_macro=false, but a few set it to true.
- version - (TODO Check) the version the setting was added. 0.0.0 if you don't know.
Further discussion
The machinery which uses the above information is not yet complete, this is why things like the id field can be left as it is among the other things.
No extraneous whitespace. You've been warned.
Be aware that the default is internally implemented as a string, so if you enter double numbers or what not for those types of params that are, you may lose precision when it passed through the strtod() function. Also, there are no interpolations or substitutions in the default. What you see is exactly what you get. This includes trailing spaces.
You may NOT add variables that:
- requires a runtime, or nonimmediate, default, like
NUM_CPUS
. You CAN however, make a default which is an expression based upon another configuration file parameter. - follow a pattern like *_FOOBAR that you cannot specify all cases to. (You'd write A_FOOBAR, B_FOOBAR, C_FOOBAR as individual cases of the above snippet). (<- TODO: Does this work at all?)
Currently, the param()
system does not EXCEPT
when an entry is not in the default table. It is our hope and dream that one day all of our entries will be in the default table and EXCEPT
will be the default case. Of course, there is an interface into param() which doesn't except no matter what, to implement those features which param() things at runtime picked out of another config file entry.
Things to Note!
- For entries in the default table, the hard coded defaults in the source code are ignored. If the variable is not in the table, the in code defaults are utilized.