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:
- Using BuddyWeb (the web interface)
- Using the BuddyWeb CLI from the command line
- 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:
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 thecdrouter -export-result
command line option.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.