-
Notifications
You must be signed in to change notification settings - Fork 107
Rucio rules created by WM
This wiki summarizes all the Rucio accounts and rules created by the WM system.
The Workload Management system has an specific service, called MSTransferor, performing the input data placement for both primary, secondary and parent input data. Most of the input data placement is performed at the Rucio dataset level, however, secondary (classic and premix) pileup are locked at the container level. Some of the attributes defined for such rules are:
-
activity
: Production Input -
lifetime
: None -
account
: wmcore_transferor -
weight
: ddm_quota -
meta
: {'workflow_group': production}. # or {'workflow_group': relval}
On what concerns the grouping
attribute, it follows this logic:
- RelVal workflows: ALL
- DQMHarvest workflows: ALL
- Nano workflows (reading MINIAODSIM): ALL
- Growing workflows (usually reading MINIAOD): DATASET
- else if it has parent data: ALL
- else: DATASET
On what concerns the RSE expression, it creates a logical OR of all the potential RSEs (considering campaign configuration, pileup configuration and site white/black list).
Lastly, if a given RSE has less than 1TB available (as a function of the RSE quota and bytes_remaining), then it will be skipped from the RSE expression.
Most of the workflows have two output data placements performed, one against DISK and the second is done for a Tape endpoint.
The DISK output data placement uses the following RSE expression: "(tier=2|tier=1)&cms_type=real&rse_type=DISK"
.
Some of the common TAPE rule attributes are:
-
activity
: Production Output -
lifetime
: 30 days. # RelVal has special config of 3 months for pre-release, otherwise it's 12 months -
account
: wmcore_output -
grouping
: ALL -
weight
: ddm_quota -
rse
: "(tier=2|tier=1)&cms_type=real&rse_type=DISK"
For the TAPE output data placement, an unique TAPE endpoint is selected for all the output containers in a given workflow. In short, its logic is:
- calculate the total required space for all of the eligible output containers of the workflow;
- using this total volume, this RSE expression
"rse_type=TAPE&wmcore_output_tape=True\cms_type=test"
and theddm_quota
attribute (the weight attribute), one TAPE endpoint is "randomly" selected.
Some of the common TAPE rule attributes are:
-
activity
: Production Output -
lifetime
: None -
account
: wmcore_output -
grouping
: ALL -
rse
: one single TAPE RSE.
Some datatiers are configured not to go do TAPE (according to the Unified configuration). In addition, note that RelVal has TAPE data placement disabled in the configuration.
This is configurable at the workflow level, during workflow assignment. If this is enabled, then an intermediate output data placement is performed by WMAgent, at the container level.
Some of the common container-level rule attributes are:
-
copies
: 2 -
activity
: Production Output -
lifetime
: None -
account
: wma_prod -
grouping
: DATASET -
rse
: '(tier=2|tier=1)&cms_type=real&rse_type=DISK'
Note that TAPE data placement is disabled in the agent, even if the workflow has been configured to have one.
While containers are growing in an active workflow, WMAgent is constantly creating dataset-level rules (CMS block) pinning the Rucio dataset at its origin site. An origin site is defined as the first RSE that receives a given file, as a result of the grid job stage out.
Some of the common dataset-level rule attributes are:
-
activity
: Production Output -
lifetime
: None -
account
: wma_prod -
grouping
: DATASET -
rse
: one DISK RSE (where the Rucio dataset is currently available).
For our testbed cluster, this setup is pretty similar, other than:
- data created by WMAgents is injected into Rucio integration, using the
wma_test
account instead ofwma_prod
; - input data placement is - at this very moment - still using Rucio production server;
- output data placement is - at this very moment - using the Rucio integration server (thus, not really functional due to the small amount of RSEs, Test RSEs and perhaps lack of attributes);