Global tracking of issues

Another extremely powerful and popular extension of the issues program is the ability to run synchronized problem tracking databases across multiple sites.

How it works

Before trying to install and use the global tracking capability of Razor, it may be useful to introduce some terminology and understand the underlying mechanisms.

One location is defined to be the primary database site (sometimes called the master site). This is where the main copy of the problem tracking database is housed. All other locations are considered secondary (or slave) sites; they work off mirrored copies of the primary database. You may have one or more secondary databases.

When an issue is created or changed at the primary site, the Razor programs form an e-mail message which is sent to a unique address at each of the secondary sites. Upon receipt of the message, programs at the secondary sites parse the message and modify the affected issue.

A slightly more involved flow occurs when an issue is created or modified at one of the secondary sites. In this situation, no changes are immediately made to the database at that site. Instead, scripts at that site generate a specially formatted e-mail message and send it to a unique address at the primary site. Upon receipt, the Razor programs parse the message and enact the requested change to the issue in the primary database. From that point, the flow is similar to the above case; the primary server generates an e-mail message back to all of the secondary sites.

Installation and set up

Installation of remote database synchronization is very straightforward; nearly all of the details are managed by the running of a single script; rz_install_remotes. Below is a sample running of that script, as it would appear when run from the primary site.

# rz_install_remotes
This script will install/update your remote database synchronization
for the issues program. One site will control the main database
and all other sites will receive updates from the main database.

Will this location have the main database? [y] y

The database synchronization is handled via email. You must define an
email address at both sites to receive updates. If you have already
run this script at the other site, respond with the email address you
defined at that time.

Local email address to be defined by this site? db_primary

Remote email address to be defined by the other site? db_secondary@slave.site

Installing remote database synchronization...

Please have your System Administrator add this line to the /etc/aliases
file or NIS table:

db_primary: "|/local/RAZOR_UNIVERSE/DOMAIN_01/++ISSUES++/Scripts/issue_catcher"

If you have not yet run this script at the other site, please do so now.

Additional remote sites may be entered in the file:
    /home/RAZOR_UNIVERSE/DOMAIN_01/++ISSUES++/Tables/Slave_sites

After running the script at the primary site, you will need to make the edits suggested in the output to the appropriate /etc/aliases files at each site. The information above is simply for the sake of an example. You will need to honor the information presented by your local execution of the script.

After having set up the primary site, the same script would be run at the secondary site(s), again honoring the suggested edits to the /etc/aliases file. Once completed, the synchronization of remote databases will be in effect.

Things to be aware of

It is important to recognize that when a user makes a change to an issue at a secondary site, it will not appear in their local database until the e-mail leaves that site to go to the primary, gets processed there, and returns in a related message. The amount of latency between the origination of a change and its manifestation in the local database will be a function of the underlying e-mail connectivity.

With this flow of events, there is an opportunity for a collision of efforts. It is possible for two people to attempt simultaneous edits to the same issue at different sites. If/when this happens, the first change that is received by the primary database server is the one that has precedence. The second change is rejected. There will be no data loss, however, as the originator of the second change will receive a message by return e-mail, explaining what the problem was. Users then have the option of re-entering the modification.

The Permissions files (which control who may bring about state changes to issues) have local jurisdiction. In other words, users at the primary site are forced to honor the local permissions. Users at the secondary site must honor the local permissions.