Subversion based CDB

Table of Contents

SCDB stands for Subversion Configuration Database. It is a complete and entirely compatible replacement for the original CVS based CDB. There is no change involved in any other Quattor component.

The only difference between SCDB and CDB is from the user (administrator) point of view : there is no longer any specific command to manage the configuration database (like cdbop). SCDB is managed using any ​Subversion client, command line or GUI (like Eclipse). This brings a lot of flexibility, compared to cdbop.

In fact original CDB is a layer over CVS to implement all the lacking features required in the context of a configuration database that may be accessed/modified by several users at the same time : transactional commit, compilation synchronization, easy access to modification history... ​Subversion, a replacement for CVS that emerged a few years ago (but after CDB design), has all these features built-in. Thus there is no need for any specific tool.

From the administrator point of view, main differences between SCDB and CDB are :

• The configuration database is nothing more than a Subversion repository/
• Use of a Subversion client to checkout/update/commit changes from/to the configuration database.
• Use of a unique tool, ant, to compile and deploy the configuration. ant is a Java replacement for make and brings portability : you can run it on every platform, including Unix, MacOS, Windows.
• Everything except deployment is done locally, on the administrator local copy of the configuration datase. That means that configuration changes can be prepared and validated disconnected from the network (​Subversion being able to do many operations, including reverting changes, disconnected).

Deployment of a new configuration is a 3 phases process :

1. Edit template modifications and compile with ant. When compilation is successful, you have a new version of the configuration that is valid (that means it can be successfully deployed). This can be done without any network connection.
2. Commit your changes to the configuration database using a ​Subversion client.
3. Deploy the new configuration with ant deploy. This involves recompiling the new configuration on the Quattor server, after tagging it (the tag is a unique timestamp). Tagging and compilation on the server are done only after successful checking of :
   • Successfull local compilation of the new configuration
   • All the local changes have been committed to the repository
   • All the changes made to the repository since last update of local copy have been incorporated into the local copy (using svn update).

As the server compile a tagged version (a specific copy of the configuration database trunk), any changes made to the trunk after the tag don't affect the deployed version (until they are deployed).