Pattern - Procedural Configuration

An alternative approach to a declarative, state-driven configuration is to be procedural, to run code that explicitly changes the machine state.

Features

• Code written in a compiled or interpreted language changes the state of the program
• The code can alter the entire machine state, or it can set up the application itself

Advantages

• Applications can configure themselves and their host systems
• Installers and GUIs can be used to set up the configuration
• In-process configuration can be very detailed
• The sequence of operations can be strongly ordered. Some CM practitioners believe that the only way to reliably recreate a configuration is to apply all operations in the same order.
• Shell and Perl scripts are easy for sysadmins to write; Application developers can use their own languages of choice, such as Ant or Java.
• When a [scripting language] is used, it is easy to change the source to fix problems.

Disadvantages

• No automatic way to detect when a system is no longer in the desired state.
• No easy way to share configuration data across parts of the system, without duplicating many values.
• Maintenance costs can be high as procedural code needs changing.
• The languages that developers like and use may not be those which the system administrators are familiar with. Even if told to run ant install or java -jar installer.jar, they may not be familiar enough with the frameworks to diagnose the causes of unfamiliar error messages. Furthermore, if the correction requires manual editing of the files, the cost of repair may be high.

SmartFrog support

Inside its Java codebase, SmartFrog is full of code that procedurally sets system state. We are, in fact, very fond of products that provide a procedural API, especially one that reports errors reliably and consistently. That does not mean that we believe that strongly ordered deployments are necessary, as long as components have their dependencies correctly declared.