Herein lies an overview of the new configuration management tool that AdamChlipala is developing.
1. Why something new?
The vast majority of configuration changes made at HCoop today go through the (already second-generation) DomainTool developed by AdamChlipala. We would have collapsed under the weight of the collective needs of our growing member base if we hadn't had something like Domtool to allow members to configure their own domains in a secure way. However, today's Domtool has some serious weaknesses. Here are a few in rough increasing order of seriousness.
Extending Domtool is painful. The source code has some nice organizing principles, but still not very many. Adding a new feature tends to involve a hearty helping of boilerplate code. This doesn't have a big effect on anyone but Adam, but there's always the issue that more complicated coding increases the risk of bugs.
It doesn't support configuration of multiple machines. Since we will be switching to running multiple machines (see ColocationPlans), this is a problem! The current Domtool could probably be patched to support this, but the other complaints make it not worth doing.
The syntax and semantics of each configuration directive are ad-hoc. New directives are added by writing custom code to parse lines of input, check that they satsify any constraints necessary for security, etc.. Just like in programming, it's nice to have a common abstraction for the basic building blocks of, in this case, configuration files.
There is no support for user-programmed abstractions. Nearly every subdirectory of /etc/domains has a .dns file with a shared prefix, declaring common elements like name servers. These should instead be calling a library function or otherwise using a reified object. All sorts of other patterns reappear frequently in Domtool configuration files and ought to be replaced with function calls.