Details
-
Sub-task
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
Description
One feature that Chris and I have talked about but never formally captured was having sub workflows. This was not a necessity on OCO, when the subject was first discussed, just as the graph based workflow was not. However, I believe it to be a useful concept moving forward to help cast processing pipelines as workflows. The idea is that any workflow could be seen as a task within another workflow. This will really help people conceptualize their workflows and facilitate the ease of maintenance and operations for the person in charge of running workflows. Currently, when a workflow is stopped how is one to proceed and resolve the issue that the workflow encounters? Is this an all or nothing proposition? If we had subworkflows a parent workflow could be blocked because of some subworkflow but instead of rerunning the whole thing the operator could decide that only a portion of that needs to be rerun (subworkflow). This brings out one logical case of where and how workflows could be broken down but I'm sure there are many others; as there are several that I have come across. Moreover, beyond maintenance and operations this would promote reuse of existing workflows and start to draw a picture of how different parts of the pipeline are related. This theoretically could cut down on initial time to set up workflows as parts that were redundant (other than just configuration) could be partitioned off as their own workflow and reused. Finally, generalizing a workflow as a task itself would help flush out the concept that conditions that a particular task (workflow) are waiting on has a bearing in the global context and should be promoted up. This would promote summarization of information and possibly ease decision making from a user and software prospective.