You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Disclaimer: meant to be a meta-issue!
This is not a core functionality for the partial pileup, but it would make the system more robust if we could actually decouple the pileup JSON dump from the workload sandbox tarball.
Currently, each pileup dump required by a workflow is created by WorkQueueManager and stored in two locations. First is in a directory tree such as:
cmst1@vocms0192:/data/srv/wmagent/current $ ls install/wmagentpy3/WorkQueueManager/cache/amaltaro_SC_6Steps_PU_Sept2023_Val_230907_205516_3876/WMSandbox/HIG_RunIISummer20UL16wmLHEGENAPV_03178_0/cmsRun3/
__init__.py pileupconf.json PSet.py
second is in the actual workflow tarball, which gets shipped to every single worker node as a condor TransferIn parameter, e.g.:
cmst1@vocms0192:/data/srv/wmagent/current $ vim install/wmagentpy3/WorkQueueManager/cache/amaltaro_SC_6Steps_PU_Sept2023_Val_230907_205516_3876/amaltaro_SC_6Steps_PU_Sept2023_Val_230907_205516_3876-Sandbox.tar.bz2
WMSandbox/HIG_RunIISummer20UL16wmLHEGENAPV_03178_0/cmsRun3/pileupconf.json
Describe the solution you'd like
This ticket proposes many changes related to transferring and loading pileup information within the payload, such as:
rename pileupconf.json to actually have an unique name based on a hash of the container name
no longer ship the pileup information inside the sandbox tarball
keep the new pileup information at the top level directory of a workflow cache (thus, in WMSandbox)
compress all the relevant pileup configuration files and transfer it as an input to the job, hence as part of TransferIn in the SimpleCondorPlugin
upon job bootstrap, uncompress the pileup tarball and leave its content at the job current directory
update SetupCMSSWPSet to actually use a hash of the pileup name to find out which JSON file to load
A tricky question is, how do we know the pileup name at the SetupCMSSWPSet level? To be investigated
Describe alternatives you've considered
Keep transferring the pileup information within the workload tarball
Additional context
Related to #11537, but I don't think it should be a sub-task of.
The text was updated successfully, but these errors were encountered:
Impact of the new feature
WMAgent
Is your feature request related to a problem? Please describe.
Disclaimer: meant to be a meta-issue!
This is not a core functionality for the partial pileup, but it would make the system more robust if we could actually decouple the pileup JSON dump from the workload sandbox tarball.
Currently, each pileup dump required by a workflow is created by WorkQueueManager and stored in two locations. First is in a directory tree such as:
second is in the actual workflow tarball, which gets shipped to every single worker node as a condor
TransferIn
parameter, e.g.:Describe the solution you'd like
This ticket proposes many changes related to transferring and loading pileup information within the payload, such as:
TransferIn
in the SimpleCondorPluginA tricky question is, how do we know the pileup name at the SetupCMSSWPSet level? To be investigated
Describe alternatives you've considered
Keep transferring the pileup information within the workload tarball
Additional context
Related to #11537, but I don't think it should be a sub-task of.
The text was updated successfully, but these errors were encountered: