History basic documentation, FsCgr tests fixup for localtime compliance, SaveInterval config on history server parsed as time.Duration

docs/advanced.rst

@@ -8,6 +8,7 @@
    cdrserver
    cdrclient
    cdrexporter
+   history
    ratinglogic
 
 

docs/cdrclient.rst

@@ -3,19 +3,21 @@ CDR Client (cdrc)
 
 It's role is to gather offline CDRs and post them to CDR Server(CDRS) component.
 
-Controlled within *cdrc* section of the configuration file.
-
 Part of the *cgr-engine*, can be started on a remote server as standalone component.
 
+Controlled within *cdrc* section of the configuration file.
+
 Has two modes of operation:
+
 - Automated: CDR file processing is triggered on file creation/move.
-- Manual: CDR file processing will be triggered at configured time interval (delay/sleep between processes).
+- Periodic: CDR file processing will be triggered at configured time interval (delay/sleep between processes) and it will be performed on all files present in the folder (IN) at run time.
 
 Principles behind functionality:
+
 - Monitor/process a CDR folder (IN) as outlined above.
-- Read every file in the folder, extract the information based on configuration and post it via configured mechanism to CDRS.
+- For every file processed, extract the information based on configuration and post it via configured mechanism to CDRS.
 - The fields extracted out of each CDR row are the same ones depicted in the CDRS documentation (following primary and extra fields concept).
-- Once the file processing completes, move it in it's original format in another folder (OUT) in order to avoid re-processing. Here it worths mentioning the auto-detection of duplicated CDRs at server side based on accid and host fields.
+- Once the file processing completes, move it in it's original format in another folder (OUT) in order to avoid re-processing. Here it's worth mentioning the auto-detection of duplicated CDRs at server side based on accid and host fields.
 
 For the moment we support processing CDRs in the following formats:
 

docs/history.rst

@@ -0,0 +1,38 @@
+Rates history 
+=============
+
+Enhances CGRateS with ability to archive rates modifications.
+
+Ability to scale by using server-agents approach. 
+In a distributed environment, there will be a single server (which can be backed up using technologies such as Linux-HA) and more agents sending the modifications to be archived.
+
+History-Server
+--------------
+
+Part of the *cgr-engine*.
+
+Controlled within *history_server* section of the configuration file.
+
+Stores rates archive in a .git folder, hence making the rating changes available for analysis via any git browser tool (eg: gitg in linux).
+
+Functionality:
+
+- On startup reads the rates archive out of .git folder and caches the data.
+- When receiving rates information from the agents it will recompile the rates cache.
+- Based on configured save interval it will dump the rating cache (if changed) into the .git archive.
+- Archives the following rating data:
+  - Destinations inside *destinations.json* file.
+  - Rating plans inside *rating_plans.json* file.
+  - Rating profiles inside *rating_profiles.json* file.
+
+History-Agent
+-------------
+
+Integrated in the rates loader components.
+
+Part of *cgr-engine* and *cgr-loader*.
+
+Enabled via *history_agent* configuration section within *cgr-engine* and *history_server* command line parameter in case of *cgr-loader*.
+
+Sends the complete rating data loaded into ratingDb to *history_server* for archiving.
+

docs/installation.rst

@@ -32,7 +32,7 @@ Since on Debian we use Daemontools_ to control the CGRateS another way to check
 3.2. Using source
 -----------------
 
-After the go environment is installed_ and configured_ issue the following commands:
+After the go environment is installed_ (at least go1.2) and configured_ issue the following commands:
 ::
 
         go get github.com/cgrates/cgrates
@@ -42,6 +42,7 @@ This command will install the trunk version of CGRateS together with all the nec
 .. _installed: http://golang.org/doc/install
 .. _configured: http://golang.org/doc/code.html
 
+
 3.3. Post-install
 -----------------
 CGRateS needs at minimum one external database where to keep it's main data as well as logs of it's operation.