-
Notifications
You must be signed in to change notification settings - Fork 158
WIP Generic QC device and late tasks as it's first adopter #2628
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
This proposes "late tasks", which can take as input merged MOs and any QOs within the same workflow. See JIRA for more deliberations about why it's probably the best approach. Definitely not finished, I'm just saving the progress and making it available for early review.
userCodeName being the task/check/aggregator/... name set by users
Barthelemy
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice, and clear, thanks a lot !
It took me quite some time to understand (again) the Actor stuff, but I am glad I made the effort because I learned a lot.
A number of classes and struct are missing documentation (just a sentence to say what it does is enough). But it is normal at this stage.
| impl::startBookkeeping(mActivity.mId, actorName, detectorName, traits::sDplProcessType, ""); | ||
| } | ||
|
|
||
| // fixme: should we just have empty methods in the base class for the sake of readability? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, that could be an idea
| #ifndef QC_HASH_DATA_DESCRIPTION_H | ||
| #define QC_HASH_DATA_DESCRIPTION_H | ||
|
|
||
| // fixme: rename to DataHeaderHelpers? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes
| std::string originStr{ actorTypeCharacterId }; | ||
| if (detectorCode.empty()) { | ||
| // fixme: that's probably a configuration error, so maybe we should just throw? | ||
| ILOG(Warning, Support) << "empty detector code for a task data origin, trying to survive with: DET" << ENDM; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is no way we can survive with DET. Just throw.
| struct LateTaskConfig : public UserCodeConfig { | ||
|
|
||
| // fixme: we should think what should happen when a user wants a critical late task relying on a non-critical QC task. | ||
| // should it be marked as resilient? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is the definition of resilient
| /// TODO: one could even consider allowing to feed late tasks with output of Reductors. | ||
| /// It could be an opportunity to refactor them as well (and rename them to Reducers, which sounds more like English). | ||
| /// TODO: to allow for more structured configuration, i see no other choice than providing the user with the late task config tree. | ||
| /// CustomParameters do not support tree-like structures. one could consider extending it, but i'm not sure if we can be fully backwards compatible. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that we do now.
This branch demonstrates how a generic Actor could be used to offload the commonalities into one place and allow for enough customizability among different QC data processors.
There is still quite a few todos, but this already demonstrates the idea.
o2-qc-run-basic and basic.json are to play with, other jsons added in the branch will not work at the moment.