Customizing Condor configuration: LOCAL_CONFIG_FILE vs LOCAL_CONFIG_DIR

Condor has a powerful configuration system. The language is powerful and so are the ways to extend default configuration.

All Condor processes, daemons/auxiliary programs/command-line tools, read configuration files in the same way. They start with what is commonly called the “global configuration file.” It is not so much global as it is a place for Condor distributors to put configuration that should be common to all installations, not to be directly edited by users. It is a place where distributors can safely change configuration between versions without having to worry about merge conflicts, and users do not have to worry about reapplying their changes.

The global configuration file is one of the following, in order:

0) Filename specified in a CONDOR_CONFIG environment variable
1) /etc/condor/condor_config
2) /use/local/etc/condor_config
3) ~condor/condor_config

For those who care, src/condor_utils/condor_config.cpp defines the order. Fedora uses /etc/condor/condor_config, allowing CONDOR_CONFIG to override.

The most important aspect of the global config file is how it enables users to extend configuration.

Historically, extension was done via the LOCAL_CONFIG_FILE. It provided a single location that a user/administrator could add configuration. It has been around for almost 15 years (since ~1997), and still works well for some use cases, such as host config files managed in a shared filesystem. However, it has a huge drawback that it requires coordinated editing. The coordination extends to features that are packaged and installed on top of Condor. Using it as a StringList does not alleviate the coordination, just extends it to the global config file.

Enter LOCAL_CONFIG_DIR, in March 2006. It provides the common configuration directory mechanism found in other systems software, such as /etc/ld.so.conf.d and /etc/yum.repo.d. It allows administrators and packages to play in a single sandbox and be properly isolated.

The way to extend Condor configuration in Fedora or Red Hat Enterprise Linux is via /etc/condor/config.d, set from LOCAL_CONFIG_DIR=/etc/condor/config.d in /etc/condor/condor_config.

But wait, you’re right, some coordination is still necessary when there is parameter overlap between files. That’s much less coordination though.

The way Condor’s configuration language works means that files read later during configuration can override parameters set in earlier files. For instance,

$ ls -l /etc/condor/config.d
total 16
-rw-r--r--. 1 root root  720 May 31 11:42 00personal_condor.config
-rw-r--r--. 1 root root 1434 May 31 11:39 61aviary.config

$ grep DAEMON_LIST /etc/condor/config.d/00personal_condor.config
DAEMON_LIST = COLLECTOR, MASTER, NEGOTIATOR, SCHEDD, STARTD

$ condor_config_val -v DAEMON_LIST
DAEMON_LIST: COLLECTOR, MASTER, NEGOTIATOR, SCHEDD, STARTD, QUERY_SERVER
  Defined in '/etc/condor/config.d/61aviary.config', line 20.

This can be handled in a few simple ways,

0) Append to parameters whenever possible, for instance above –

$ grep DAEMON_LIST /etc/condor/config.d/61aviary.config
DAEMON_LIST = $(DAEMON_LIST), QUERY_SERVER

1) Separate user managed files from package managed files –

Prefix all files with two-digit numbers with the following ranges:

. 00 – reserved for a default config, e.g. 00personal_condor.config
. 10-40 – user/admin configuration files
. 50-80 – packaged configuration files
. 99 – reserved for features requiring control of configuration

Finally, if you still need to use LOCAL_CONFIG_FILE, you can always set it within a configuration file under /etc/condor/config.d.

Tags: Condor, Configuration