• Home
• knowledge-base
• CDRouter 10.0 Major Update Notice

General Notice

CDRouter 10.0 introduced a brand new web interface and a number of architectural changes. As part of this update, most buddy and BuddyWeb branding and references have been removed from CDRouter. These changes have been undertaken in an effort to eliminate confusion and focus marketing on the core product CDRouter instead of its various components.

This page provides an overview of the the major components and summarizes the changes that have been made, the motivation for making these changes, and the potential impact on existing users.

History

The test harness component of CDRouter was originally referred to as buddy. The buddy command was the original CLI used to control CDRouter and execute test cases. The web component of CDRouter, originally referred to as BuddyWeb, was added at a later date. What was BuddyWeb will now simply be referred to as CDRouter’s web interface.

BuddyWeb also included a separate web CLI component referred to as the BuddyWeb CLI. This interface was designed to make automation and scripting of CDRouter’s web interface easier.

As a result, users have historically had three ways to control CDRouter:

1. Using BuddyWeb (the web interface)
2. Using the BuddyWeb CLI from the command line
3. Using buddy from the command line

BuddyWeb and the BuddyWeb CLI have many advantages over buddy, and are typically the recommended interfaces for interacting with a CDRouter system.

Name Mapping

As part of this update a number of core CDRouter components and their associated commands have been renamed. The following table provides a mapping between the old and new command names:

Original Command Name	New Command Name
buddy	cdrouter-cli
buddyweb	cdrouter
buddy-diag	cdrouter-diag

The original buddy, buddyweb, and buddy-diag commands are still available but have been deprecated and will be removed in future releases. For a short period of time the both commands will continue to work, although all users are encouraged to update any impacted scripts to use the new commands as soon as possible to avoid testing downtime.

Note that the arguments associated with the new commands are compatible with the original commands. Updating scripts should be a simple matter of changing the command name.

CDRouter’s web interface is now registered under the service cdrouter. The following table provides a mapping between the old and new commands for controlling CDRouter’s web interface:

Original Command Name	New Command Name
/etc/init.d/buddyweb [start\|stop\|restart\|status]	/etc/init.d/cdrouter [start\|stop\|restart\|status]
service buddyweb [start\|stop\|restart\|status]	service cdrouter [start\|stop\|restart\|status]

Please note that the old buddyweb service no longer exists, and any impacted scripts must be updated immediately.

Please see the CDRouter Web CLI Guide for more information on scripting with CDRouter’s web CLI. Information associated with the cdrouter-cli interface can be found in the main CDRouter User Guide.

Directory Structure

This update also changes the underlying directory structure of all test results generated using CDRouter’s web interface or the web CLI. Previously, all data associated with BuddyWeb, including test results generated using BuddyWeb or the BuddyWeb CLI command were located in the /usr/buddyweb directory. CDRouter’s web interface and test results now reside in the following directories:

Resources	Original Directory	New Directory
Main data directory for web interface	/usr/buddyweb	/usr/cdrouter-data
Metadata directory for web interface	/usr/buddyweb/db	/usr/cdrouter-data/data
Test results directory	/usr/buddyweb/results	/usr/cdrouter-data/results

Note that all results generated using BuddyWeb or the BuddyWeb CLI in earlier versions of CDRouter will remain in the /usr/buddyweb directory. Pointers to this data will be added to the new database, but the actual files will not be moved.

Upgrading

Due to a change in the format used by CDRouter to store its data, a migration process is required to migrate configurations, packages and results from a pre-10.0 CDRouter installation.

Migrating Configurations and Packages

The first time the CDRouter 10.0 installer is run on a pre-10.0 CDRouter system, it will automatically migrate all configurations and packages. The migration process is part of the installer’s output:

Trying to migrate testpaths, configs, packages

Migrating custom testpaths... done.
Migrating configs... done.
Migrating packages... done.

2 of 2 custom testpaths were migrated successfully
81 of 81 configs were migrated successfully
110 of 110 packages were migrated successfully

Total time 2s

Migration of testpaths, configs, packages marked as completed in /usr/cdrouter-data/etc/config.yml

Migrating Results

The migration of results can take considerable time depending on the number of results on the system and is therefore not done automatically. Please see this Knowledge Base article for information on migrating your results.

Downgrading

Downgrading from CDRouter 10.0 is supported, with a few caveats. To downgrade, simply run a pre-10.0 CDRouter installer.

Configurations and Packages

After downgrading, configurations and packages which existed before the 10.0 upgrade will exist exactly as they did before the upgrade was performed. Changes made to those configurations or packages while running 10.0 will not be present after downgrading. New configurations or packages created while running 10.0 will not exist.

Results

After downgrading, results which existed before the 10.0 upgrade will still exist. The exception is if a pre-10.0 result is deleted while running 10.0. In this case, after the downgrade the result will be listed on the result index page but an error will be shown when trying to view that result. New results created while running 10.0 will not exist.

CSV Output of Results

Note that the format of the CSV file generated from the web interface for an individual result has changed. Any scripts that utilize the CSV file may have to be updated. For more information, please contact support@qacafe.com.

Results Export Format

The results export format has changed as part of this release. It is now a binary file as opposed to an archive of the result directory on disk. The new format generates a .gz file that is designed to be imported into another CDRouter system. This new file is not meant to be read, parsed, or manipulated outside of CDRouter.

Within the web interface there are two different result exports available:

1. The new export archive in .gz format described above. This is available by clicking on the Export button on the Results page or by using the cdrouter -export-result command line option.

2. A logdir archive. This is available by clicking on the Open Log Directory link on the Results page and then clicking the Export button. There is currently no cdrouter command line option for this export type. Note that these exports also cannot be imported into CDRouter because they do not have the database component that is found in the export archive above.

Using the API to Obtain a Logdir Archive

Users that have been relying on parsing data from the previous result export format are encouraged to investigate CDRouter’s new and powerful web API .

Using the API it is possible to download the logdir archive which is similar to the format of previous releases. If automatic login is enabled, wget can be used to download the logdir archive using the following API call:

wget  --output-document=20160310230336.tgz "http://10.0.0.56:8015/api/v1/results/20160310230336/logdir?format=tgz"

If you have automatic login disabled, an API token must be provided using the wget --header option (note that API tokens are displayed for each user on the Admin > Users page):

wget --header="Authorization: Bearer c13518dc"  --output-document=20160310230336.tgz "http://10.0.0.56.lan:8015/api/v1/results/20160310230336/logdir?format=tgz"

Note that the wget --output-document option specifies the name of the downloaded file.