>if a bundle with two actions - one FAILED due to coordinator submission >error, other KILLED), bundle is supposed to KILLED bq. Bundle should be >FAILED and not KILLED. Only when user has KILLED the bundle, should >its >status be KILLED.
Currently if one of coord job submit fails, Oozie will issue Kill command to kill bundle job and all started/created coord job. So Bundle status will be in killed state. We have to fix that. More detail @https://issues.apache.org/jira/browse/OOZIE-1863. Puru. On 9/18/14, 5:49 PM, "Mona Chitnis" <mona.chit...@yahoo.in> wrote: > >bq. if a bundle with two actions - one FAILED due to coordinator >submission error, other KILLED), bundle is supposed to KILLED bq. >Bundle should be FAILED and not KILLED. Only when user has KILLED the >bundle, should its status be KILLED. > >Thanks for minor correction. I was shooting for bundle will _not_ be >DONEWITHERROR, which Bowen said he's observing > Mona Chitnis >Software Engineer, Hadoop Team >Yahoo! > > > > On Thursday, September 18, 2014 5:09 PM, Rohini Palaniswamy ><rohini.adi...@gmail.com> wrote: > > > bq. Shouldn't oozie be intelligent enough to do a no-op on a killed >coord job? There are options now to resume a killed coord job. If new >end time was applied on other coord jobs and not applied on that one, >user needs to know. >bq. if a bundle with two actions - one FAILED due to coordinator >submission error, other KILLED), bundle is supposed to KILLED Bundle >should be FAILED and not KILLED. Only when user has KILLED the bundle, >should its status be KILLED. >-Rohini >On Thu, Sep 18, 2014 at 4:09 PM, Purshotam Shah ><purus...@yahoo-inc.com.invalid> wrote: > >Bowen, >JIRA has explanation. Please update JIRA if you see any issue with >approach. > >>Why is it a good idea to throw an exception if one of the coord jobs is >>in "killed" state? In the BundleJobChangeXCommand, the code doesn't even >>attempt to change the coord job. Shouldn't oozie be intelligent >enough >>to do a no-op on a killed coord job? > > > >To let user know the list of coord jobs for which change is not applied. > > >Puru. > >On 9/18/14, 2:11 PM, "bowen zhang" <bowenzhang...@yahoo.com.INVALID> >wrote: > >>Hi Purshotam, >>Why is it a good idea to throw an exception if one of the coord jobs is >>in "killed" state? In the BundleJobChangeXCommand, the code doesn't even >>attempt to change the coord job. Shouldn't oozie be intelligent enough to >>do a no-op on a killed coord job? >>Bowen >> >> >> >>________________________________ >> From: Purshotam Shah <purus...@yahoo-inc.com.INVALID> >>To: "dev@oozie.apache.org" <dev@oozie.apache.org>; Mona Chitnis >><mona.chit...@yahoo.in>; bowen zhang <bowenzhang...@yahoo.com> >>Sent: Wednesday, September 17, 2014 6:17 PM >>Subject: Re: issue after OOZIE-1807 >> >> >>Hi Bowen, >> BundleJobChangeXCommand command will get applied to bundle and coord >>jobs. It will aggregate message for all killed coord jobs and throw them >>as exception. >>It is similar to chmod command. >> >>JIRA has more details. Let me know if you need any other information. >> >>Puru. >> >> >> >> >> >>On 9/17/14, 6:05 PM, "Mona Chitnis" <mona.chit...@yahoo.in> wrote: >> >>> >>>Puru, >>>Bowen just gave me a call regarding this issue. Can you answer his >>>question? That'll be faster than me digging through the code. >>> Mona Chitnis >>>Yahoo! >>> >>> On Wednesday, September 17, 2014 5:51 PM, bowen zhang >>><bowenzhang...@yahoo.com.INVALID> wrote: >>> >>> >>> Hi guys, >>> >>>Purshatom, I see you checked oozie-1807 into the trunk. So, I have a >>>question, why does it need to throw an exception when someone wants to >>>change a bundle job where one of its coord job is in KILLED state? Due >>>to >>>the change in BundleJobChangeXCommand, this is throwing exceptions when >>>trying to change a RUNNING bundle job where some of the coord jobs are >>>intentionally killed by the user. >>>Thanks, >>>Bowen >>> >>> >>> > > > > > >
