Page History

Turn Off History

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: 

[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.3/3_3Configuration.html#SECTION
tags=master,master
id=552

The attributes that you really need to care about are default, type, usage, friendly_name, url, 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. Please make sure the above entries are defined. For url just leave it be the example set forth above.

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.
  2. 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.

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.