| | 1 | = Subversion based CDB = |
| | 2 | [[TracNav]] |
| | 3 | |
| | 4 | [[TOC(inline)]] |
| | 5 | |
| | 6 | 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. |
| | 7 | |
| | 8 | 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 [http://subversion.tigris.com Subversion] client, command line or GUI (like Eclipse). This brings a lot of flexibility, compared to `cdbop`. |
| | 9 | |
| | 10 | 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... [http://subversion.tigris.com 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. |
| | 11 | |
| | 12 | From the administrator point of view, main differences between SCDB and CDB are : |
| | 13 | |
| | 14 | * The configuration database is nothing more than a Subversion repository/ |
| | 15 | * Use of a Subversion client to checkout/update/commit changes from/to the configuration database. |
| | 16 | * 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. |
| | 17 | * 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 ([http://subversion.tigris.com Subversion] being able to do many operations, '''including reverting changes''', disconnected). |
| | 18 | |
| | 19 | Deployment of a new configuration is a 3 phases process : |
| | 20 | 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. |
| | 21 | 1. Commit your changes to the configuration database using a [http://subversion.tigris.com Subversion] client. |
| | 22 | 1. 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 : |
| | 23 | * Successfull local compilation of the new configuration |
| | 24 | * All the local changes have been committed to the repository |
| | 25 | * All the changes made to the repository since last update of local copy have been incorporated into the local copy (using `svn update`). |
| | 26 | |
| | 27 | 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). |
| | 28 | |
| | 29 | To ensure that no change will break any part of the configuration, there is no choice but doing a recompile of all the machine profiles affected by changes (`ant` always take care of recompiling only profiles with a dependency on changes but it requires all templates present in the configuration database to have a valid syntax, whether they are used or not). |
| | 30 | |
| | 31 | SCDB supports all PAN features, including ''namespaces''. Unlike original CDB, 'namespaces' bring no additionnal complexity : namespaces are matched to directory in template hierarchy. |
| | 32 | |
