Data Distribution of Conditions and Configuration Datasets

[ DataDist  |   |  ]

This page describes the required steps to import Conditions Database (CDB) or Configuration Database (CfgDB) snapshots implemented in ROOT. The basic steps involved are:

  1. Pick the proper dataset and tag in the bookkeeping.
  2. Transfer the dataset files to the local site and make it accessible to clients (e.g.: nfs, Xrootd)..
  3. Update the naming rules files in order to point to the new snapshot.
More information about the root based CDB adn CfgDB are found on the Root based Conditions and Configurations page.

!!!! This page is still under construction. !!!

Naming Rules: KanAccess and Co.

The ROOT based implementation of the CDB and CfgDB requires to translate a

generic file name   -->   logical file name (LFN)
and
logical file name (LFN)   -->   physical file name (PFN)

The translation from LFN to PFN is done using the KanAccess.cfg using the same mechanism used for the event-store root files.

The translation from a generic name to the LFN is new for the nonevent-store files. The rules how to translate the names are stored in (name rules) config files. For the CDB this file is CdbNameRules.cfg and for the CfgDB it is CfgDBNameRules.cfg

This example shows the different names for a CDB snapshot file: 
  generic name: cdb_o259_c0_p7_i0.root
  LFN: /store/cdb/cond18boot/betamini/2006/04/20060419T091147/CDB-20060419T091147-cdb_o259_c0_p7_i0.root
  PFN: xrootd://rdr-a////store/cdb/cond18boot/betamini/2006/04/20060419T091147/CDB-20060419T091147-cdb_o259_c0_p7_i0.root

KanAccess.cfg

If you do not have it already at your site, you should create a configuration file for Kanga data access which defines the translation rules from the "logical file name" (LFN) to a "physical file name" (PFN). The name of the file is $BFROOT/kanga/config/KanAccess.cfg. For the full description of the KanAccess.cfg file format check "friendly" BaBar web, it should be somewhere there. Translation rules for Configuration and Conditions databases have to be added to the KanAccess.cfg file. If your site uses xrootd as SLAC, this can look like: 
# CfgDB
read /store/cfg/* xrootd kanolb-a:1094/
write /store/cfg/* error

# CDB
read /store/cdb/* xrootd kanolb-a:1094/
write /store/cdb/* error
If you prefer to access the database using the ordinary file system, then it might look like: 
# CfgDB
read /store/cfg/* file /work/cfgdb-root
write /store/cfg/* error

#CDB
read /store/cdb/* file /work/cdb-root
write /store/cdb/* error
To check that it works as expected run the following command:
> KanAccess /store/cfg/CfgDB.root
Its output should print the path to the intended storage space, either xrootd or a file system directory.

Configuration Database Name Rules

The ROOT implementation of the configuration database uses its own rules to translate the generic name of the ROOT file into a logical file name of a specific snapshot name. For this you need to create the file with the name
$BFROOT/kanga/config/cfgdb/CfgDBNameRules.cfg
with the following content (or copy it from SLAC): 
# we don't allow writing to a generic DB
write /cfg/CfgDB\.root error
# generic name translation for the most recent snapshot
-include kanga/config/cfgdb/CfgDBNameRules-latest.cfg

As you can see this file has an include statement for another file (CfgDBNameRules-latest.cfg, the path is relative to $BFROOT). This file is usually a link to a file that is specific to a snapshot. For example 

 CfgDBNameRules-latest.cfg -> CfgDBNameRules-20060425T183631.cfg
with 
 > cat CfgDBNameRules-20060425T183631.cfg
   read /cfg/CfgDB\.root /store/cfg/2006/04/CfgDB-20060425T183631.root

The script KanUpdateRulesCfgDB from the package KanNonEventUtils is used to update the link and created the proper configuration file. The argument to the script is the CfgDB name: 

  KanUpdateRulesCfgDB /store/cfg/2006/04/CfgDB-20060425T183631.root

Note that the directory where the rules file lives should be writable by the person who will be running the update script. This script should only be ran once the snapshot is available for the clients.

Conditions Database Name Rules

The CDB employs the same structure for the config files and name rules as used for the CfgDB. The name rules file is:

$BFROOT/kanga/config/cdb/CdbNameRules.cfg
Unlike the for the CfgDB this file might contain more then one include directive because different types of conditions snapshots exist (e.g.: cond18boot-betamini, cond18boot-full, ..). The content might be: 

 # we don't allow writing to a generic DB
 write /cdb/cdb_boot\.root error
 # generic name translation for "cond18boot betamini" snapshot
 -include kanga/config/cdb/CdbNameRules-cond18boot-betamini.cfg
 # generic name translation for "cond18boot full" snapshot
 -include kanga/config/cdb/CdbNameRules-cond18boot-full.cfg
Again the include files are usually links to files that are specific for a snapshot. The script KanUpdateRulesCDB in package KanNonEventUtils is used to create these files: 
  > KanUpdateRulesCDB /store/cdb/cond18boot/betamini/2006/04/20060419T091147/CDB-20060419T091147-cdb_boot.root
would create the file CdbNameRules-cond18boot-betamini-20060419T091147.cfg and CdbNameRules-cond18boot-betamini.cfg would point to it.
Last modified: Thu Jul 20 10:19:05 PDT 2006