Move config & control DDS functionality into plugins.

This commit is contained in:
Alexey Rybalchenko 2016-10-19 16:20:40 +02:00
parent a1424e13fb
commit f18c6e50e2
4 changed files with 44 additions and 57 deletions

View File

@ -6,17 +6,13 @@
# copied verbatim in the file "LICENSE" #
################################################################################
configure_file(${CMAKE_SOURCE_DIR}/examples/MQ/3-dds/ex3-dds-topology.xml
${CMAKE_BINARY_DIR}/bin/config/ex3-dds-topology.xml)
configure_file(${CMAKE_SOURCE_DIR}/examples/MQ/3-dds/ex3-dds-hosts.cfg
configure_file(${CMAKE_SOURCE_DIR}/examples/MQ/3-dds/ex3-dds-topology.xml
${CMAKE_BINARY_DIR}/bin/config/ex3-dds-topology.xml @ONLY)
configure_file(${CMAKE_SOURCE_DIR}/examples/MQ/3-dds/ex3-dds-hosts.cfg
${CMAKE_BINARY_DIR}/bin/config/ex3-dds-hosts.cfg COPYONLY)
configure_file(${CMAKE_SOURCE_DIR}/examples/MQ/3-dds/ex3-dds.json
configure_file(${CMAKE_SOURCE_DIR}/examples/MQ/3-dds/ex3-dds.json
${CMAKE_BINARY_DIR}/bin/config/ex3-dds.json COPYONLY)
If(DDS_FOUND)
add_definitions(-DDDS_FOUND)
EndIf(DDS_FOUND)
Set(INCLUDE_DIRECTORIES
${CMAKE_SOURCE_DIR}/fairmq
${CMAKE_SOURCE_DIR}/fairmq/zeromq
@ -31,7 +27,6 @@ Set(INCLUDE_DIRECTORIES
Set(SYSTEM_INCLUDE_DIRECTORIES
${SYSTEM_INCLUDE_DIRECTORIES}
${Boost_INCLUDE_DIR}
${DDS_INCLUDE_DIR}
${ZMQ_INCLUDE_DIR}
)
@ -55,9 +50,6 @@ Set(SRCS
Set(DEPENDENCIES
${DEPENDENCIES}
FairMQ
${DDS_INTERCOM_LIBRARY_SHARED}
${DDS_PROTOCOL_LIBRARY_SHARED}
${DDS_USER_DEFAULTS_LIBRARY_SHARED}
)
set(LIBRARY_NAME FairMQExample3)

View File

@ -3,29 +3,21 @@ Example 3: DDS
This example demonstrates usage of the Dynamic Deployment System ([DDS](http://dds.gsi.de/)) to dynamically deploy and configure a topology of devices. The topology is similar to those of Example 2, but now it can be easily distributed on different computing nodes without the need for manual socket reconfiguration of the devices.
This example is compiled only if the DDS is found by CMake. Custom DDS installation location can be given to CMake like this:
To make use of DDS functionality the example executables need to find the DDS plugin libraries that are compiled with FairRoot when FairRoot find DDS installed. DDS location is given to CMake as follows:
```bash
cmake -DDDS_PATH="/path/to/dds/install/dir/" ..
```
The description below outlines the minimal steps needed to run the example with DDS. For more details please refer to DDS documentation on [DDS Website](http://dds.gsi.de/).
The description below outlines the minimal steps needed to run the example with DDS. For general DDS help please refer to DDS documentation on [DDS Website](http://dds.gsi.de/).
##### 1. After beginning the initialization, the device handles the socket addresses and ports distribution via DDS.
##### 1. The device handles the socket addresses and ports configuration via DDS Plugin.
The binding channels give their bound addresses to devices interested in connecting to it and connecting sockets wait to receive these addresses. This match happens via the properties specified in the JSON file, which replace addresses in the DDS run. This is done behind the scenes after the initialization has been started and can be called with a single method call:
It is sufficient to provide the `--config <ddsConfigPluginLibraryName>` (and `--control <ddsControlPluginLibraryName>` if state machine control is to be handled with DDS) command line arguments to let the devices be configured dynamically. No code changes in the device are necessary. See the XML topology file for example of using the command line arguments.
```C++
sampler.ChangeState("INIT_DEVICE");
HandleConfigViaDDS(sampler);
sampler.WaitForEndOfState("INIT_DEVICE");
```
##### 2. Write DDS hosts file that contains a list of worker nodes to run the topology on (When deploying using the SSH plug-in).
In most cases a device will land on a random node and all the addresses and ports are configured dynamicaly. The JSON file does not contain any address information for a DDS run. Instead, addresses are exchanged between the devices dynamically based on the provided property names. E.g. here a processor communicates with the sampler via the *data1* channel. Sampler (binding) communicates its address to the processor(s) (connecting) via the "samplerAddr" property (see `ex3-dds.json` file).
##### 3. Write DDS hosts file that contains a list of worker nodes to run the topology on (When deploying using the SSH plug-in).
We run this example on the local machine for simplicity. The file below defines one worker `wn0` with 12 DDS Agents (thus able to accept 12 tasks). The parameters for each worker node are:
We run this example on the local machine for simplicity. The file below defines three workers, sampler, processor and sink, with a total of 12 DDS agents (thus able to accept 12 tasks). The parameters for each worker node are:
- user-chosen worker ID (must be unique)
- a host name with or without a login, in a form: login@host.fqdn (password-less SSH access to these hosts must be possible)
- additional SSH params (can be empty)
@ -34,20 +26,23 @@ We run this example on the local machine for simplicity. The file below defines
```bash
@bash_begin@
echo "DBG: SSH ENV Script"
#source setup.sh
@bash_end@
wn0, username@localhost, , /tmp/, 12
sampler, username@localhost, , /path/to/dds-work-dir/, 1
processor, username@localhost, , /path/to/dds-work-dir/, 10
sink, username@localhost, , /path/to/dds-work-dir/, 1
```
##### 4. Write DDS topology file that describes which tasks (processes) to run and their topology and configuration.
##### 3. Write DDS topology file that describes which tasks (processes) to run and their topology and configuration.
Take a look at `ex3-dds-topology.xml`. It consists of a definition part (properties, tasks, collections and more) and execution part (main). In our example Sampler, Processor and Sink tasks are defines, containing their executables and exchanged properties. The `<main>` of the topology uses the defined tasks. Besides one Sampler and one Sink task, a group containing Processor task is defined. The group has a multiplicity of 10, meaninig 10 Processors will be executed. Each of the Processors will receive the properties with Sampler and Sink addresses.
The configuration of the channel connection addresses is done by the DDS plugin via the channel names. The task property names must correspond to the channel names (data1, data2), with binding channels writing the properties and connecting channel reading the properties (see the example XML and JSON files).
If `eth0` network interface (default for binding) is not available on your system, specify another one in the topology file for each task. For example: `--network-interface lo0`.
##### 5. Start DDS server.
##### 4. Start DDS server.
The DDS server is started with:
@ -55,38 +50,38 @@ The DDS server is started with:
dds-server start -s
```
##### 6. Submit DDS Agents (configured in the hosts file).
##### 5. Submit DDS Agents (configured in the hosts file).
Agents are submitted with:
```bash
dds-submit --rms ssh --config ex3-dds-hosts.cfg
```
The `--rms` option defines a destination resource management system. The `--config` specifies an SSH plug-in resource definition file.
The `--rms` option defines a destination resource management system. The `--config` specifies an SSH plug-in resource definition file.
##### 7. Set the topology file.
##### 6. Set the topology file.
Point DDS to the topology file:
```bash
dds-topology --set ex3-dds-topology.xml
```
##### 8. Activate the topology.
##### 7. Activate the topology.
```bash
dds-topology --activate
```
##### 9. Run
##### 8. Run
After activation, agents will execute the defined tasks on the worker nodes. Output of the tasks will be stored in the directory that was specified in the hosts file.
##### 10. (optional) Use example command UI to check state of the devices
##### 9. (optional) Use example command UI to check state of the devices
This example includes a simple utility to send commands to devices and receive replies from them. The code in `runDDSCommandUI.cxx` (compiled as ex3-dds-command-ui) uses the DDS intercom library to send "check-state" string to all devices, to which they reply with their ID and state they are in. The utility also allows requesting state changes from devices. This can be used as an example of sending/receiving commands or other information to devices.
A simple utility (fairmq-dds-command-ui) is included with FairRoot to send commands to devices and receive replies from them. The utility uses the DDS intercom library to send "check-state" string to all devices, to which they reply with their ID and state they are in. The utility also allows requesting state changes from devices. To let the device listen to the commands from the utility, start the device with `--control <ddsControlPluginLibraryName>` cmd option (see example XML topology).
To see it in action, start the ex3-dds-command-ui while the topology is running.
To see it in action, start the fairmq-dds-command-ui while the topology is running.
##### 11. Stop DDS server/topology.
##### 10. Stop DDS server/topology.
The execution of tasks can be stopped with:
```bash
@ -97,4 +92,4 @@ Or by stopping the DDS server:
dds-server stop
```
For a more complete DDS documentation please refer to [DDS Website](http://dds.gsi.de/).
For general DDS documentation please refer to [DDS Website](http://dds.gsi.de/).

View File

@ -1,7 +1,7 @@
<topology id="ExampleDDS">
<property id="samplerAddr" />
<property id="sinkAddr" />
<property id="data1" />
<property id="data2" />
<declrequirement id="SamplerWorker">
<hostPattern type="wnname" value="sampler"/>
@ -16,27 +16,27 @@
</declrequirement>
<decltask id="Sampler">
<exe reachable="true">@CMAKE_BINARY_DIR@/bin/examples/MQ/3-dds/ex3-sampler --id sampler --log-color false --control dds --mq-config @CMAKE_BINARY_DIR@/bin/config/ex3-dds.json</exe>
<exe reachable="true">@CMAKE_BINARY_DIR@/bin/examples/MQ/3-dds/ex3-sampler --id sampler --log-color false --control libFairMQDDSControlPlugin.so --config libFairMQDDSConfigPlugin.so --mq-config @CMAKE_BINARY_DIR@/bin/config/ex3-dds.json</exe>
<requirement>SamplerWorker</requirement>
<properties>
<id access="write">samplerAddr</id>
<id access="write">data1</id>
</properties>
</decltask>
<decltask id="Processor">
<exe reachable="true">@CMAKE_BINARY_DIR@/bin/examples/MQ/3-dds/ex3-processor --id processor_%taskIndex% --config-key processor --log-color false --control dds --mq-config @CMAKE_BINARY_DIR@/bin/config/ex3-dds.json</exe>
<exe reachable="true">@CMAKE_BINARY_DIR@/bin/examples/MQ/3-dds/ex3-processor --id processor_%taskIndex% --config-key processor --log-color false --control libFairMQDDSControlPlugin.so --config libFairMQDDSConfigPlugin.so --mq-config @CMAKE_BINARY_DIR@/bin/config/ex3-dds.json</exe>
<requirement>ProcessorWorker</requirement>
<properties>
<id access="read">samplerAddr</id>
<id access="read">sinkAddr</id>
<id access="read">data1</id>
<id access="read">data2</id>
</properties>
</decltask>
<decltask id="Sink">
<exe reachable="true">@CMAKE_BINARY_DIR@/bin/examples/MQ/3-dds/ex3-sink --id sink --log-color false --control dds --mq-config @CMAKE_BINARY_DIR@/bin/config/ex3-dds.json</exe>
<exe reachable="true">@CMAKE_BINARY_DIR@/bin/examples/MQ/3-dds/ex3-sink --id sink --log-color false --control libFairMQDDSControlPlugin.so --config libFairMQDDSConfigPlugin.so --mq-config @CMAKE_BINARY_DIR@/bin/config/ex3-dds.json</exe>
<requirement>SinkWorker</requirement>
<properties>
<id access="write">sinkAddr</id>
<id access="write">data2</id>
</properties>
</decltask>

View File

@ -7,9 +7,9 @@
"channel":
{
"name": "data1",
"property": "samplerAddr",
"type": "push",
"method": "bind"
"method": "bind",
"rateLogging": "0"
}
},
{
@ -17,15 +17,15 @@
"channels":
[{
"name": "data1",
"property": "samplerAddr",
"type": "pull",
"method": "connect"
"method": "connect",
"rateLogging": "0"
},
{
"name": "data2",
"property": "sinkAddr",
"type": "push",
"method": "connect"
"method": "connect",
"rateLogging": "0"
}]
},
{
@ -33,9 +33,9 @@
"channel":
{
"name": "data2",
"property": "sinkAddr",
"type": "pull",
"method": "bind"
"method": "bind",
"rateLogging": "0"
}
}]
}