{section: Adding Configuration File Parameters to Condor}

The method by which condor_configurations file parameters are to be added into Condor has changed. Sadly, this method I'm describing right now is also deprecated, and will be replaced by a completely new system shortly. Until then,
however, this is what you do:

There is a file called =src/condor_c++_util/param_info.in= and in it are definitions like this:

{verbatim}
[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://cs.wisc.edu/condor/manual/v7.1/3_3Configuration.html#SECTION
tags=master,master
id=552
{endverbatim}

The attributes that you really need to care about are *default, type, usage, friendly_name*, and *tags*. If you can predict *customization* and *reconfig*, which take values =seldom=, =often=, =always=, and =true= on a reconfig, =false= otherwise, respectively, then fill that in as well. The others can be held constant when you make a new entry by copying the snippet above and changing it.

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. Also, *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.

Now, there are some restrictions to what kind of param var you can add with the current system. These restrictions will be lifted in the future as more and more of the implementation of this feature set comes online.

You may *NOT* add variables that:
1: 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.
1: 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).

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.

I know this isn't as cool as it could be, nor flexible. But once I get the next version of the param_info.in file finished that uses a *much* better syntax, and allows pattern variables and runtime defaults things will become much more sane. This feature (#123) is still in flux.

{subsection: Things to Note!}

1: 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.