This has been confirmed by the growing adoption of Quattor, by both large commercial organisations [1] and academic institutions, most of them using the tool-kit to manage consistently their grid and non-grid systems.
The challenge of structuring and sharing components in a collaborative system is not new; over the years programming language designers have attacked this problem from many angles.
At the core of Quattor is Pan, a high-level, typed language with flexible include mechanisms, a range of data structures, and validation features familiar to modern programmers.
There is no single “correct” model for a devolved infrastructure, thus great flexibility is needed in the architecture of the configuration system itself.
Only the Pan compiler is strictly necessary in a Quattor system; the other two subsystems can be replaced by any service providing similar functionality.
Quattor's modular architecture allows the three configuration management subsystems to be deployed in either a distributed or centralized fashion.
In the distributed approach, profile compilation (at development stage) is carried out on client systems, templates are then checked into a suitable database, and finally the deployment is initiated by invoking a separate operation on the server.
In this section, we focus only on the Pan features that are relevant to devolved management of distributed sites: validation, configuration reuse, and modularization.
The extensive validation features in the Pan language maximize the probability of finding configuration problems at compile time, minimizing costly clean-ups of deployed misconfiguration.
With respect to the original design, two new features have been developed to promote modularization and large-scale reuse of configurations: the name-spacing and load-path mechanisms.
A full site configuration typically consists of a large number of templates organized into directories and subdirectories.
The QWG templates use all of the features of Pan to allow distributed sites to share grid middleware expertise.
A key feature for administering large distributed infrastructures is the ability to automatically install machines, possibly from a remote location.
Current AII modules use node profiles to configure DHCP servers, PXE boot and Kickstart-guided installations.
However, the above-mentioned technologies allow the transparent implementation of multi-site installations, by setting up a central server and appropriate relays using standard protocols.
A dispatcher program running on the node performs an analysis of the freshly retrieved configuration for changes in the relevant sections, and triggers the appropriate components.