address PR comments

Author: Barthelemy

README.md

@@ -41,8 +41,6 @@ For a general overview of our (O2) software, organization and processes, please
     * [Naming convention](doc/ModulesDevelopment.md#naming-convention)
     * [Committing code](doc/ModulesDevelopment.md#committing-code)
     * [Data sources](doc/ModulesDevelopment.md#data-sources)
-        * [Readout](doc/ModulesDevelopment.md#readout)
-        * [DPL workflow](doc/ModulesDevelopment.md#dpl-workflow)
     * [Run number and other run attributes (period, pass type, provenance)](doc/ModulesDevelopment.md#run-number-and-other-run-attributes-period-pass-type-provenance)
     * [A more advanced example](doc/ModulesDevelopment.md#a-more-advanced-example)
 * [Framework](doc/Framework.md)
@@ -99,7 +97,6 @@ For a general overview of our (O2) software, organization and processes, please
     * [Get all the task output to the infologger](doc/FLPsuite.md#get-all-the-task-output-to-the-infologger)
     * [Using a different config file with the general QC](doc/FLPsuite.md#using-a-different-config-file-with-the-general-qc)
     * [Enable the repo cleaner](doc/FLPsuite.md#enable-the-repo-cleaner)
-    * [Definition of new arguments](doc/FLPsuite.md#definition-of-new-arguments)
     * [Reference data](doc/FLPsuite.md#reference-data)
 * [Miscellaneous](doc/Miscellaneous.md)
     * [Asynchronous Data and Monte Carlo QC operations](doc/Miscellaneous.md#asynchronous-data-and-monte-carlo-qc-operations)

doc/DevelopersTips.md

@@ -562,3 +562,27 @@ Just run aliBuild with following parameters from the folder with prepared alidis
 ```
 aliBuild build QualityControl --defaults o2 --docker --architecture slc8_x86-64
 ```
+
+## Instructions to move an object in the QCDB
+
+The script `o2-qc-repo-move-objects` lets the user move an object, and thus all the versions attached to it. E.g.:
+
+```
+python3 o2-qc-repo-move-objects --url http://ccdb-test.cern.ch:8080 --path qc/TST/MO/Bob --new-path qc/TST/MO/Bob2 --log-level 10 
+```
+
+## Definition of new arguments
+
+One can also tell the DPL driver to accept new arguments. This is done using the `customize` method at the top of your workflow definition (usually called "runXXX" in the QC).
+
+For example, to add two parameters of different types do :
+
+```
+void customize(std::vector<ConfigParamSpec>& workflowOptions)
+{
+  workflowOptions.push_back(
+    ConfigParamSpec{ "config-path", VariantType::String, "", { "Path to the config file. Overwrite the default paths. Do not use with no-data-sampling." } });
+  workflowOptions.push_back(
+    ConfigParamSpec{ "no-data-sampling", VariantType::Bool, false, { "Skips data sampling, connects directly the task to the producer." } });
+}
+```

doc/FLPsuite.md

@@ -10,7 +10,6 @@ FLP Suite
    * [Get all the task output to the infologger](#get-all-the-task-output-to-the-infologger)
    * [Using a different config file with the general QC](#using-a-different-config-file-with-the-general-qc)
    * [Enable the repo cleaner](#enable-the-repo-cleaner)
-   * [Definition of new arguments](#definition-of-new-arguments)
    * [Reference data](#reference-data)
 <!--te-->
 
@@ -114,22 +113,6 @@ By defaults there is a _disabled_ cron job :
 3. update the cron job to use the modified config file
 4. uncomment the cron job
 
-## Definition of new arguments
-
-One can also tell the DPL driver to accept new arguments. This is done using the `customize` method at the top of your workflow definition (usually called "runXXX" in the QC).
-
-For example, to add two parameters of different types do :
-
-```
-void customize(std::vector<ConfigParamSpec>& workflowOptions)
-{
-  workflowOptions.push_back(
-    ConfigParamSpec{ "config-path", VariantType::String, "", { "Path to the config file. Overwrite the default paths. Do not use with no-data-sampling." } });
-  workflowOptions.push_back(
-    ConfigParamSpec{ "no-data-sampling", VariantType::Bool, false, { "Skips data sampling, connects directly the task to the producer." } });
-}
-```
-
 ## Reference data
 
 A reference object is an object from a previous run. It is usually used as a point of comparison.

doc/ModulesDevelopment.md

@@ -25,8 +25,6 @@
 * [Naming convention](#naming-convention)
 * [Committing code](#committing-code)
 * [Data sources](#data-sources)
-   * [Readout](#readout)
-   * [DPL workflow](#dpl-workflow)
 * [Run number and other run attributes (period, pass type, provenance)](#run-number-and-other-run-attributes-period-pass-type-provenance)
 * [A more advanced example](#a-more-advanced-example)
 <!--te-->
@@ -450,65 +448,7 @@ General ALICE Git guidelines can be accessed [here](https://alisw.github.io/git-
 
 ## Data sources
 
-In the final system, the qc gets real data from the DPL devices or the readout processes. During development a number of possibilities are available for the detector teams to develop their QC. We list them below. 
-
-### Readout
-
-When connecting the QC directly to the readout using the `o2-qc-run-readout` proxy, remember to add this consumer to the config file of the readout and to enable it: 
-```json
-[consumer-fmq-qc]
-consumerType=FairMQChannel
-enableRawFormat=1
-fmq-name=readout-qc
-fmq-address=ipc:///tmp/readout-pipe-1
-fmq-type=pub
-fmq-transport=zeromq
-unmanagedMemorySize=2G
-memoryPoolNumberOfPages=500
-memoryPoolPageSize=1M
-enabled=1
-```
-
-__Random data__
-
-Add one or several dummy equipments:
-```
-[equipment-dummy-1]
-name=dummy-1
-equipmentType=dummy
-enabled=1
-eventMaxSize=200
-eventMinSize=100
-memoryPoolNumberOfPages=100
-memoryPoolPageSize=128k
-fillData=1
-```
-
-__Live detector data__
-
-If a part or the whole detector is ready and connected to 1 or several CRUs in the FLP, configure the readout to get data from there. The exact configuration items should be discussed with the readout experts. 
-
-This is the most realistic test one can do but it is also not very practical as you have to control the data taking and be on the machine equipped with a CRU. See the next section to alleviate this situation.
-
-__Detector data file__
-
-To record a data file with readout while getting data from a CRU, add the following piece to the readout configuration file:
-```
-[consumer-rec]
-enabled=1
-consumerType=fileRecorder
-fileName=/tmp/dataRecorder_flp1.raw
-```
-
-To read it back with readout, for instance on another machine, add: 
-```
-[equipment-player-1]
-equipmentType=player
-memoryPoolPageSize=1M
-memoryPoolNumberOfPages=1000
-filePath=/path/to/dataRecorder_flp1.raw 
-autoChunk=1
-```
+In the final system, the qc gets real data from the DPL devices or the readout processes. During development a number of possibilities are available for the detector teams to develop their QC. We list them below.
 
 ### DPL workflow
 

doc/QCDB.md

@@ -33,13 +33,15 @@ The detector name and the taskname are set in the config file :
 
 ```json
 "tasks": {
-  "QcTask": {       <---------- task name
+  "QcTask": {       <---------- task ID
     "active": "true",
+    "taskName": "QcTask",   <--------- task name
     "className": "o2::quality_control_modules::skeleton::SkeletonTask",
     "moduleName": "QcSkeleton",
     "detectorName": "TST",       <---------- detector name
 ```
 
+If the task name is not specified then we use the task ID.
 The quality is stored as a CCDB metadata of the object.
 
 ## Custom metadata for QC objects in the QCDB
@@ -61,14 +63,6 @@ It is also possible to add or update metadata of a MonitorObject directly:
   mo->addOrUpdateMetadata(key, value);
 ```
 
-## Instructions to move an object in the QCDB
-
-The script `o2-qc-repo-move-objects` lets the user move an object, and thus all the versions attached to it. E.g.:
-
-```
-python3 o2-qc-repo-move-objects --url http://ccdb-test.cern.ch:8080 --path qc/TST/MO/Bob --new-path qc/TST/MO/Bob2 --log-level 10 
-```
-
 ## Accessing objects in CCDB
 
 The recommended way (excluding postprocessing) to access the run conditions in the _CCDB_ is to use a `Lifetime::Condition` DPL input, which can be requested as in the query below: