Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
3.3.0
-
None
Description
The current logic of the purge service is flat. I.e., WF purging only takes into account WF end time, it does not take into account that the WF was started by a COORD job. This means that completed WFs of a running COORD job could be purge if the COORD job runs for longer that the purge age.
One way of addressing this would be:
- WF purging only purges WF jobs started directly by a client call.
- COORD purging purges COORD jobs started directly by a client call. It also purges the WF jobs created by the COORD jobs being purged.
- BUNDLE purging purges BUNDLE jobs, and the corresponding COORD jobs and WF jobs.
This could be handled by a new property in the job beans 'job-owner'. Set to 'self' it would mean it can be purged by the same job type purger. If set to other value, then it is a higher level purger the one responsible for purging it.
This means that for a WF job started by COORD job started by a BUNDLE job, the WF job and the COORD job would have the BUNDLE job as owner, while the BUNDLE with have 'self' as owner.
This ownership propagation would also have
A caveat here would be how to handle sub-workflows.
I guess we should check if the wf was created from coord, and if then let the coord purge take care of that, meaning wf purge does not purge wf started by coords.
Similarly, the same should also apply for sub-WFs.
Attachments
Attachments
Issue Links
- breaks
-
OOZIE-1449 Coordinator Workflow parent relationship is broken for purge service
- Closed
- depends upon
-
OOZIE-1264 The "parent" property of a subworkflow should be the ID of the parent workflow
- Closed
- links to