openvdm.yaml
server/etc/openvdm.yaml is the server-side configuration file, read by the Gearman
workers. The installer builds it from openvdm.yaml.dist if it doesn’t exist, and
leaves an existing one alone, so when upgrading merge your settings
into the new release’s file.
Top-Level Keys
| Key | Default | Description |
|---|---|---|
siteRoot |
http://127.0.0.1/ |
URL of the OpenVDM web app, used by the workers to reach its REST API |
workerApiKey |
(generated by the installer) | Shared secret the workers send in the X-Worker-Token header. Must match WORKER_API_KEY in Config.php |
transferInterval |
5 |
Minutes between scheduled collection system transfers |
gearmanServer |
localhost:4730 |
Gearman job server, as host:port |
showOnlyCurrentCruiseDir |
False |
Hide every directory in CruiseData except the current cruise’s |
transferPublicData |
True |
Copy the contents of the PublicData share into the cruise directory |
logfilePurgeTimedelta |
(commented out) | Maximum age of transfer log files, e.g. "12 hours" |
plugins |
Where the data dashboard plugins are. See plugins | |
hooks |
Gearman tasks to run after other tasks. See hooks | |
postHookCommands |
Commands to run after lifecycle events. See postHookCommands |
workerApiKey
The web app’s REST API leaves transfer passwords out of its responses unless the request
carries this key. Without it, the workers don’t get transfer passwords and transfers
that use one fail. The installer generates a key and writes it here and to
Config.php; to set one by hand, use a long random string in both files, e.g.
openssl rand -hex 32.
plugins
plugins:
pluginDir: "./server/plugins"
pluginSuffix: "_plugin.py"
pluginDir is the directory with the plugins, relative to the
OpenVDM root. A collection system transfer’s plugin is
<transfer name in lower case><pluginSuffix>.
hooks
Maps a Gearman task to the tasks to start, in the background, after it succeeds. The
defaults chain the data dashboard and MD5 summary updates onto each transfer, and start
the postHookCommands events:
hooks:
runCollectionSystemTransfer:
- updateDataDashboard
- updateMD5Summary
- postCollectionSystemTransfer
updateDataDashboard:
- updateMD5Summary
- postDataDashboard
setupNewCruise:
- postSetupNewCruise
...
Leave these as they are unless you’re adding your own Gearman worker.
postHookCommands
Commands to run at lifecycle events. Each key is an event; its commandList is run in
order. Under postCollectionSystemTransfer and postDataDashboard, each entry also
names the collection system transfer it applies to. Give each command as a list of
arguments, with full paths:
postHookCommands:
postSetupNewCruise:
commandList:
- name: "Setup Remote Cruise Directories"
command:
- /opt/openvdm/venv/bin/python
- /opt/openvdm/bin/build_remote_directory.py
- "-s"
postDataDashboard:
- collectionSystemTransferName: OpenRVDAS
commandList:
- name: "Build cruise tracks"
command:
- /opt/openvdm/venv/bin/python
- /opt/openvdm/bin/build_cruise_tracks.py
- OpenRVDAS
Events
| Key | Runs… |
|---|---|
postSetupNewCruise |
After a new cruise is set up |
postSetupNewLowering |
After a new lowering is set up |
postCollectionSystemTransfer |
After a collection system transfer completes |
postDataDashboard |
After a data dashboard update or rebuild completes |
preFinalizeCurrentCruise |
Before the cruise is finalized |
postFinalizeCurrentCruise |
After the cruise is finalized, before its cruise data transfers |
preFinalizeCurrentLowering |
Before the lowering is finalized |
postFinalizeCurrentLowering |
After the lowering is finalized |
Tokens
Command arguments can include these tokens, which are replaced when the command runs:
| Token | Value |
|---|---|
{cruiseID} |
Current cruise ID |
{loweringID} |
Current lowering ID |
{newFiles} |
Space-separated list of the newly transferred files |
{updatedFiles} |
Space-separated list of the updated files |
{collectionSystemTransferID} |
ID of the collection system transfer |
{collectionSystemTransferName} |
Name of the collection system transfer |
See Post-Hook Commands for examples.