Bcfg2 was designed with several goals in mind. This section will describe those goals, and how they were manifested in the design. This section will also define important concepts used in Bcfg2.

Model configurations using declarative semantics. Declarative semantics maximize the utility of configuration management tools; they provide the most flexibility for the tool to determine the right course of action in any given situation. This means that users can focus on the task of describing the desired configuration, while leaving the task of transitioning clients states to the tool. Configuration descriptions should be comprehensive. This means that configurations served to the client should be sufficent to reproduce all desired functionality. This assumption allows the use of heuristics to detect extra configuration, aiding in reliable, comprehensive configuration definitions. Provide a flexible approach to user interactions. Most configuration management systems take a rigid approach to user interactions; that is, either the client system is always correct, or the central system is. This means that users are forced into an overly proscribed model where the system asserts where correct data is. Configuration data modification is frequently undertaken on both the configuration server and clients. Hence, the existance of a single canonical data location can easily pose a problem during normal tool use. Bcfg2 takes a different approach. The default assumption is that data on the server is correct, however, the client has option to run in another mode where local changes are catalogued for server-side integration. If the Bcfg2 client is run in dry run mode, it can help to reconcile differences between current client state and the configuration described on the server. The Bcfg2 client also searches for extra configuration; that is, configuration that is not specified by the configuration description. When extra configuration is found, either configuration has been removed from the configuration description on the server, or manual configuration has occurred on the client. Options related to two-way verification and removal are useful for configuration reconciliation when interactive access is used. Generators, and administrative applications. Imcremental operations.

Bundles Bundles are groups of interdependent configuration elements. Service configurations including software, configuration files, and service activations are a good example of bundles. When any of these components are modified, all should be re-checked, and any associated services should be restarted. We refer to this process as coherent reconfiguration; this guarentees that all configuration changes are active before reconfiguration has completed. Metadata