[jira] [Commented] (OODT-211) Sub Workflows

["Christopher Warner (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OODT-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052120#comment-13052120 ] 

Christopher Warner commented on OODT-211:
-----------------------------------------

I'm not sure I exactly understand this part of the proposal:

"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)."

1. Do you mean rerunning the subworkflow only and/or the rest of a parent workflow routine? Wouldn't one have to already have the subworkflow cut up into different sub workflows ahead of time? So you'd have to walk through the process a couple of times etc?

2. What do you mean by promoted up? Doesn't this just mean workflows will need dependency? Workflow dependency on other workflows completion etc etc?

> Sub Workflows
> -------------
>
>                 Key: OODT-211
>                 URL: https://issues.apache.org/jira/browse/OODT-211
>             Project: OODT
>          Issue Type: Sub-task
>          Components: workflow manager
>            Reporter: Paul Ramirez
>            Assignee: Chris A. Mattmann
>             Fix For: 0.4
>
>
> 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.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira