## File: bcm.overview ## First created: 9/25/01 ## Authors: Eric Roman ## Description: One page description of BCM ## $Id: bcm.overview,v 1.1 2001/10/09 01:39:19 eroman Exp $ BCM stands for Berkeley Configuration Manager. BCM compiles the root file file systems for cluster nodes. BCM reads a configuration file containing a description of the cluster and processes this configuration file through a series of _actions_. The configuration file specifies the attributes of the nodes in the cluster. Actions then read node attributes, and build the file system accordingly. We designed BCM to manage our test clusters. Our test clusters present a real challenge to most cluster tools. We have a mixture of Pentium II, Athlon, Pentium IV, and Alpha nodes. Some of our nodes have local disks (SCSI, IDE, and FC in the future), others are diskless. Our nodes have a mixture of 128MB, 256MB, 512MB and 1GB of memory. Our M-VIA test nodes have 6 different types of Ethernet cards. Our PC cluster nodes have a mixture of GigaBit Ethernet, Myrinet, and GigaNet NICs. We also need to run different kernels on the nodes to test kernel changes. Despite these differences, there is some commonality between our nodes. We wanted a tool that could accurately capture commonality between nodes, but could also handle the strongly heterogenous nature of our cluster. To meet our needs, we require a tool that has both a very flexible format for describing node configurations, and a simple, extensible structure to adapt to new situations. Our configuration format is unique in two ways. One, we have make use of a special type of inheritance. Inheritance acts as a mechanism to describe strongly heterogenous configurations in a compact form, and without the use of a complicated data model. Second, our configuration format does not specify attributes for cluster nodes. Attributes are completely arbitrary. Users are free to describe their cluster in any format they see fit. BCM is optimized for environments where configuration changes are common. BCM is designed to allow users to create any cluster they want. _Actions_ provide the flexibility necessary to adapt BCM to new configurations. Actions are simple modules that do some amount of work to build the cluster. Actions are designed to be easy to write. An action module takes a description of a node as an argument, and performs some action to build the node. Our current implementation uses action modules to build PXE images, EtherBoot images, and bootable floppy images for cluster nodes. Other actions install RPMs into a filesystem, or customize files on a file system. Customization of files is accomplished through _Customization Trees_. A Customization Tree action walks through the inheritance hierarchy for a node and copies files from the node's parent classes into the node's root filesystem. For example, if a user requires a different /etc/hosts.allow file, say, on 'node6', he simply creates a file 'custom/node6/etc/hosts.allow'. If that file is required on all hosts that inherit from a class 'class_A', the file is moved to 'custom/class_A/etc/hosts.allow'. The customization tree code just copies this file into the node's root filesystem when invoked. Customization trees also support a form of macro processing, so that configuration files may be generated automatically at run time. This allows us to provide a single base class definition for files like '/etc/sysconfig/ifcfg-eth0', which must be different for each node, without requiring us to write special code to generate this configuration file. The ifcfg-eth0 file is just placed into a customization tree, and macro expansion does the rest. One interesting feature of the BCM configuration language is that macros, or any other scalar attribute, may expand to a string of code interpreted at run time. BCM, although it can successfully create an arbitrary root file system, cannot transfer a root file system. This is done for three reasons. One, we need to be able to handle a cluster with both diskless nodes, and nodes hosting a root file system. Two, we want to be able to interoperate with an arbitrary transfer agent without requiring our users to choose one (or use an existing one). Three, the cluster's final configuration is kept in one location; there is only one point of contact for the administrator. Since BCM cannot transfer a file system, it requires a transfer agent to move a compiled root file system to the client node. This agent might be SystemImager, rsync, part of the Chiba City toolkit, or NFS. We have tested BCM in an NFS root environment. We plan to expand BCM's role in cluster configuration management. Our current configuration language provides a simple, concise and very general means to identify and document cluster configurations. We are looking to make BCM better at configuration accounting and auditing. We also plan to add an RPC interface to action modules, so that action modules can be run in parallel, or on remote nodes.