[jira] [Updated] (OOZIE-1685) Oozie doesn’t process correctly workflows with a non-default name node
[ https://issues.apache.org/jira/browse/OOZIE-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Zhitomirsky updated OOZIE-1685: Attachment: oozie-1685.7.patch ShareLibService#getFileSystem now simply returns fs as Rohini pointed out Oozie doesn’t process correctly workflows with a non-default name node -- Key: OOZIE-1685 URL: https://issues.apache.org/jira/browse/OOZIE-1685 Project: Oozie Issue Type: Bug Components: core Affects Versions: trunk Environment: Any Reporter: Benjamin Zhitomirsky Fix For: trunk Attachments: Design of the fix OOZIE-1685-rev1.docx, oozie-1685-trunk.patch, oozie-1685-trunk.patch, oozie-1685-trunk.patch, oozie-1685.1.patch, oozie-1685.2.patch, oozie-1685.3.patch, oozie-1685.4.patch, oozie-1685.5.patch, oozie-1685.6.patch, oozie-1685.7.patch Original Estimate: 168h Remaining Estimate: 168h When name-node element in Oozie workflow specifies a name node different from the default one (specified in core-site.xml), the following functionality doesn’t work properly: - Location of libraries specified via oozie.service.WorkflowAppService.system.libpath. Oozie first (during launcher configuration) tries to locate them using name node specified by the name-node element, but later during job submission it expects this path to be under the default Oozie name node - Processing of the job-xml element if job xml is specified via absolute path. Oozie tries locate it under the default Oozie name node instead of the name-node specified in action. Specifying non-default name node makes a lot of sense in Azure environment, because it allows to submit the same job to different Hadoop clusters. I will submit a fix for CR soon. Please refer attached short document for more information. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OOZIE-1685) Oozie doesn’t process correctly workflows with a non-default name node
[ https://issues.apache.org/jira/browse/OOZIE-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Zhitomirsky updated OOZIE-1685: Attachment: oozie-1685.6.patch Oozie doesn’t process correctly workflows with a non-default name node -- Key: OOZIE-1685 URL: https://issues.apache.org/jira/browse/OOZIE-1685 Project: Oozie Issue Type: Bug Components: core Affects Versions: trunk Environment: Any Reporter: Benjamin Zhitomirsky Fix For: trunk Attachments: Design of the fix OOZIE-1685-rev1.docx, oozie-1685-trunk.patch, oozie-1685-trunk.patch, oozie-1685-trunk.patch, oozie-1685.1.patch, oozie-1685.2.patch, oozie-1685.3.patch, oozie-1685.4.patch, oozie-1685.5.patch, oozie-1685.6.patch Original Estimate: 168h Remaining Estimate: 168h When name-node element in Oozie workflow specifies a name node different from the default one (specified in core-site.xml), the following functionality doesn’t work properly: - Location of libraries specified via oozie.service.WorkflowAppService.system.libpath. Oozie first (during launcher configuration) tries to locate them using name node specified by the name-node element, but later during job submission it expects this path to be under the default Oozie name node - Processing of the job-xml element if job xml is specified via absolute path. Oozie tries locate it under the default Oozie name node instead of the name-node specified in action. Specifying non-default name node makes a lot of sense in Azure environment, because it allows to submit the same job to different Hadoop clusters. I will submit a fix for CR soon. Please refer attached short document for more information. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OOZIE-1685) Oozie doesn’t process correctly workflows with a non-default name node
[ https://issues.apache.org/jira/browse/OOZIE-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Zhitomirsky updated OOZIE-1685: Attachment: oozie-1685.5.patch CR comments applied Oozie doesn’t process correctly workflows with a non-default name node -- Key: OOZIE-1685 URL: https://issues.apache.org/jira/browse/OOZIE-1685 Project: Oozie Issue Type: Bug Components: core Affects Versions: trunk, 3.3.2, 4.0.0 Environment: Any Reporter: Benjamin Zhitomirsky Fix For: trunk Attachments: Design of the fix OOZIE-1685-rev1.docx, oozie-1685-trunk.patch, oozie-1685-trunk.patch, oozie-1685-trunk.patch, oozie-1685.1.patch, oozie-1685.2.patch, oozie-1685.3.patch, oozie-1685.4.patch, oozie-1685.5.patch Original Estimate: 168h Remaining Estimate: 168h When name-node element in Oozie workflow specifies a name node different from the default one (specified in core-site.xml), the following functionality doesn’t work properly: - Location of libraries specified via oozie.service.WorkflowAppService.system.libpath. Oozie first (during launcher configuration) tries to locate them using name node specified by the name-node element, but later during job submission it expects this path to be under the default Oozie name node - Processing of the job-xml element if job xml is specified via absolute path. Oozie tries locate it under the default Oozie name node instead of the name-node specified in action. Specifying non-default name node makes a lot of sense in Azure environment, because it allows to submit the same job to different Hadoop clusters. I will submit a fix for CR soon. Please refer attached short document for more information. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OOZIE-1685) Oozie doesn’t process correctly workflows with a non-default name node
[ https://issues.apache.org/jira/browse/OOZIE-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Zhitomirsky updated OOZIE-1685: Attachment: oozie-1685.4.patch Fixed a too long line in twiki file. Oozie doesn’t process correctly workflows with a non-default name node -- Key: OOZIE-1685 URL: https://issues.apache.org/jira/browse/OOZIE-1685 Project: Oozie Issue Type: Bug Components: core Affects Versions: trunk, 3.3.2, 4.0.0 Environment: Any Reporter: Benjamin Zhitomirsky Fix For: trunk Attachments: Design of the fix OOZIE-1685-rev1.docx, oozie-1685-trunk.patch, oozie-1685-trunk.patch, oozie-1685-trunk.patch, oozie-1685.1.patch, oozie-1685.2.patch, oozie-1685.3.patch, oozie-1685.4.patch Original Estimate: 168h Remaining Estimate: 168h When name-node element in Oozie workflow specifies a name node different from the default one (specified in core-site.xml), the following functionality doesn’t work properly: - Location of libraries specified via oozie.service.WorkflowAppService.system.libpath. Oozie first (during launcher configuration) tries to locate them using name node specified by the name-node element, but later during job submission it expects this path to be under the default Oozie name node - Processing of the job-xml element if job xml is specified via absolute path. Oozie tries locate it under the default Oozie name node instead of the name-node specified in action. Specifying non-default name node makes a lot of sense in Azure environment, because it allows to submit the same job to different Hadoop clusters. I will submit a fix for CR soon. Please refer attached short document for more information. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OOZIE-1685) Oozie doesn’t process correctly workflows with a non-default name node
[ https://issues.apache.org/jira/browse/OOZIE-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Zhitomirsky updated OOZIE-1685: Attachment: oozie-1685.1.patch Fixed small bug with second fs detection. Please vote! Oozie doesn’t process correctly workflows with a non-default name node -- Key: OOZIE-1685 URL: https://issues.apache.org/jira/browse/OOZIE-1685 Project: Oozie Issue Type: Bug Components: core Affects Versions: trunk, 3.3.2, 4.0.0 Environment: Any Reporter: Benjamin Zhitomirsky Fix For: trunk Attachments: Design of the fix OOZIE-1685-rev1.docx, oozie-1685-trunk.patch, oozie-1685-trunk.patch, oozie-1685-trunk.patch, oozie-1685.1.patch Original Estimate: 168h Remaining Estimate: 168h When name-node element in Oozie workflow specifies a name node different from the default one (specified in core-site.xml), the following functionality doesn’t work properly: - Location of libraries specified via oozie.service.WorkflowAppService.system.libpath. Oozie first (during launcher configuration) tries to locate them using name node specified by the name-node element, but later during job submission it expects this path to be under the default Oozie name node - Processing of the job-xml element if job xml is specified via absolute path. Oozie tries locate it under the default Oozie name node instead of the name-node specified in action. Specifying non-default name node makes a lot of sense in Azure environment, because it allows to submit the same job to different Hadoop clusters. I will submit a fix for CR soon. Please refer attached short document for more information. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OOZIE-1685) Oozie doesn’t process correctly workflows with a non-default name node
[ https://issues.apache.org/jira/browse/OOZIE-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Zhitomirsky updated OOZIE-1685: Attachment: oozie-1685-trunk.patch Oozie doesn’t process correctly workflows with a non-default name node -- Key: OOZIE-1685 URL: https://issues.apache.org/jira/browse/OOZIE-1685 Project: Oozie Issue Type: Bug Components: core Affects Versions: trunk, 3.3.2, 4.0.0 Environment: Any Reporter: Benjamin Zhitomirsky Fix For: trunk Attachments: Design of the fix OOZIE-1685-rev1.docx, oozie-1685-trunk.patch, oozie-1685-trunk.patch Original Estimate: 168h Remaining Estimate: 168h When name-node element in Oozie workflow specifies a name node different from the default one (specified in core-site.xml), the following functionality doesn’t work properly: - Location of libraries specified via oozie.service.WorkflowAppService.system.libpath. Oozie first (during launcher configuration) tries to locate them using name node specified by the name-node element, but later during job submission it expects this path to be under the default Oozie name node - Processing of the job-xml element if job xml is specified via absolute path. Oozie tries locate it under the default Oozie name node instead of the name-node specified in action. Specifying non-default name node makes a lot of sense in Azure environment, because it allows to submit the same job to different Hadoop clusters. I will submit a fix for CR soon. Please refer attached short document for more information. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OOZIE-1685) Oozie doesn’t process correctly workflows with a non-default name node
[ https://issues.apache.org/jira/browse/OOZIE-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Zhitomirsky updated OOZIE-1685: Attachment: oozie-1685-trunk.patch Oozie doesn’t process correctly workflows with a non-default name node -- Key: OOZIE-1685 URL: https://issues.apache.org/jira/browse/OOZIE-1685 Project: Oozie Issue Type: Bug Components: core Affects Versions: trunk, 3.3.2, 4.0.0 Environment: Any Reporter: Benjamin Zhitomirsky Fix For: trunk Attachments: Design of the fix OOZIE-1685-rev1.docx, oozie-1685-trunk.patch, oozie-1685-trunk.patch, oozie-1685-trunk.patch Original Estimate: 168h Remaining Estimate: 168h When name-node element in Oozie workflow specifies a name node different from the default one (specified in core-site.xml), the following functionality doesn’t work properly: - Location of libraries specified via oozie.service.WorkflowAppService.system.libpath. Oozie first (during launcher configuration) tries to locate them using name node specified by the name-node element, but later during job submission it expects this path to be under the default Oozie name node - Processing of the job-xml element if job xml is specified via absolute path. Oozie tries locate it under the default Oozie name node instead of the name-node specified in action. Specifying non-default name node makes a lot of sense in Azure environment, because it allows to submit the same job to different Hadoop clusters. I will submit a fix for CR soon. Please refer attached short document for more information. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OOZIE-1685) Oozie doesn’t process correctly workflows with a non-default name node
[ https://issues.apache.org/jira/browse/OOZIE-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Zhitomirsky updated OOZIE-1685: Fix Version/s: 4.0.0 trunk Oozie doesn’t process correctly workflows with a non-default name node -- Key: OOZIE-1685 URL: https://issues.apache.org/jira/browse/OOZIE-1685 Project: Oozie Issue Type: Bug Components: core Affects Versions: trunk Environment: Any Reporter: Benjamin Zhitomirsky Labels: patch Fix For: trunk Attachments: Design of the fix OOZIE-1685.docx Original Estimate: 168h Remaining Estimate: 168h When name-node element in Oozie workflow specifies a name node different from the default one (specified in core-site.xml), the following functionality doesn’t work properly: - Location of libraries specified via oozie.service.WorkflowAppService.system.libpath. Oozie first (during launcher configuration) tries to locate them using name node specified by the name-node element, but later during job submission it expects this path to be under the default Oozie name node - Processing of the job-xml element if job xml is specified via absolute path. Oozie tries locate it under the default Oozie name node instead of the name-node specified in action. Specifying non-default name node makes a lot of sense in Azure environment, because it allows to submit the same job to different Hadoop clusters. I will submit a fix for CR soon. Please refer attached short document for more information. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OOZIE-1685) Oozie doesn’t process correctly workflows with a non-default name node
[ https://issues.apache.org/jira/browse/OOZIE-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Zhitomirsky updated OOZIE-1685: Affects Version/s: 3.3.2 4.0.0 Oozie doesn’t process correctly workflows with a non-default name node -- Key: OOZIE-1685 URL: https://issues.apache.org/jira/browse/OOZIE-1685 Project: Oozie Issue Type: Bug Components: core Affects Versions: trunk, 3.3.2, 4.0.0 Environment: Any Reporter: Benjamin Zhitomirsky Labels: patch Fix For: trunk, 3.3.2, 4.0.0 Attachments: Design of the fix OOZIE-1685.docx Original Estimate: 168h Remaining Estimate: 168h When name-node element in Oozie workflow specifies a name node different from the default one (specified in core-site.xml), the following functionality doesn’t work properly: - Location of libraries specified via oozie.service.WorkflowAppService.system.libpath. Oozie first (during launcher configuration) tries to locate them using name node specified by the name-node element, but later during job submission it expects this path to be under the default Oozie name node - Processing of the job-xml element if job xml is specified via absolute path. Oozie tries locate it under the default Oozie name node instead of the name-node specified in action. Specifying non-default name node makes a lot of sense in Azure environment, because it allows to submit the same job to different Hadoop clusters. I will submit a fix for CR soon. Please refer attached short document for more information. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OOZIE-1685) Oozie doesn’t process correctly workflows with a non-default name node
[ https://issues.apache.org/jira/browse/OOZIE-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Zhitomirsky updated OOZIE-1685: Fix Version/s: 3.3.2 4.0.0 Oozie doesn’t process correctly workflows with a non-default name node -- Key: OOZIE-1685 URL: https://issues.apache.org/jira/browse/OOZIE-1685 Project: Oozie Issue Type: Bug Components: core Affects Versions: trunk, 3.3.2, 4.0.0 Environment: Any Reporter: Benjamin Zhitomirsky Labels: patch Fix For: trunk, 3.3.2, 4.0.0 Attachments: Design of the fix OOZIE-1685.docx Original Estimate: 168h Remaining Estimate: 168h When name-node element in Oozie workflow specifies a name node different from the default one (specified in core-site.xml), the following functionality doesn’t work properly: - Location of libraries specified via oozie.service.WorkflowAppService.system.libpath. Oozie first (during launcher configuration) tries to locate them using name node specified by the name-node element, but later during job submission it expects this path to be under the default Oozie name node - Processing of the job-xml element if job xml is specified via absolute path. Oozie tries locate it under the default Oozie name node instead of the name-node specified in action. Specifying non-default name node makes a lot of sense in Azure environment, because it allows to submit the same job to different Hadoop clusters. I will submit a fix for CR soon. Please refer attached short document for more information. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OOZIE-1685) Oozie doesn’t process correctly workflows with a non-default name node
[ https://issues.apache.org/jira/browse/OOZIE-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Zhitomirsky updated OOZIE-1685: Labels: (was: patch) Oozie doesn’t process correctly workflows with a non-default name node -- Key: OOZIE-1685 URL: https://issues.apache.org/jira/browse/OOZIE-1685 Project: Oozie Issue Type: Bug Components: core Affects Versions: trunk, 3.3.2, 4.0.0 Environment: Any Reporter: Benjamin Zhitomirsky Fix For: trunk, 3.3.2, 4.0.0 Attachments: Design of the fix OOZIE-1685.docx Original Estimate: 168h Remaining Estimate: 168h When name-node element in Oozie workflow specifies a name node different from the default one (specified in core-site.xml), the following functionality doesn’t work properly: - Location of libraries specified via oozie.service.WorkflowAppService.system.libpath. Oozie first (during launcher configuration) tries to locate them using name node specified by the name-node element, but later during job submission it expects this path to be under the default Oozie name node - Processing of the job-xml element if job xml is specified via absolute path. Oozie tries locate it under the default Oozie name node instead of the name-node specified in action. Specifying non-default name node makes a lot of sense in Azure environment, because it allows to submit the same job to different Hadoop clusters. I will submit a fix for CR soon. Please refer attached short document for more information. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OOZIE-1685) Oozie doesn’t process correctly workflows with a non-default name node
[ https://issues.apache.org/jira/browse/OOZIE-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Zhitomirsky updated OOZIE-1685: Attachment: oozie-1685-trunk.patch oozie-1685_branch-4.0.patch oozie-1685_branch-3.3.patch Oozie doesn’t process correctly workflows with a non-default name node -- Key: OOZIE-1685 URL: https://issues.apache.org/jira/browse/OOZIE-1685 Project: Oozie Issue Type: Bug Components: core Affects Versions: trunk, 3.3.2, 4.0.0 Environment: Any Reporter: Benjamin Zhitomirsky Fix For: trunk, 3.3.2, 4.0.0 Attachments: Design of the fix OOZIE-1685-rev1.docx, Design of the fix OOZIE-1685.docx, oozie-1685-trunk.patch, oozie-1685_branch-3.3.patch, oozie-1685_branch-4.0.patch Original Estimate: 168h Remaining Estimate: 168h When name-node element in Oozie workflow specifies a name node different from the default one (specified in core-site.xml), the following functionality doesn’t work properly: - Location of libraries specified via oozie.service.WorkflowAppService.system.libpath. Oozie first (during launcher configuration) tries to locate them using name node specified by the name-node element, but later during job submission it expects this path to be under the default Oozie name node - Processing of the job-xml element if job xml is specified via absolute path. Oozie tries locate it under the default Oozie name node instead of the name-node specified in action. Specifying non-default name node makes a lot of sense in Azure environment, because it allows to submit the same job to different Hadoop clusters. I will submit a fix for CR soon. Please refer attached short document for more information. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OOZIE-1685) Oozie doesn’t process correctly workflows with a non-default name node
[ https://issues.apache.org/jira/browse/OOZIE-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Zhitomirsky updated OOZIE-1685: Attachment: Design of the fix OOZIE-1685-rev1.docx Revision 1 Oozie doesn’t process correctly workflows with a non-default name node -- Key: OOZIE-1685 URL: https://issues.apache.org/jira/browse/OOZIE-1685 Project: Oozie Issue Type: Bug Components: core Affects Versions: trunk, 3.3.2, 4.0.0 Environment: Any Reporter: Benjamin Zhitomirsky Fix For: trunk, 3.3.2, 4.0.0 Attachments: Design of the fix OOZIE-1685-rev1.docx, Design of the fix OOZIE-1685.docx, oozie-1685-trunk.patch, oozie-1685_branch-3.3.patch, oozie-1685_branch-4.0.patch Original Estimate: 168h Remaining Estimate: 168h When name-node element in Oozie workflow specifies a name node different from the default one (specified in core-site.xml), the following functionality doesn’t work properly: - Location of libraries specified via oozie.service.WorkflowAppService.system.libpath. Oozie first (during launcher configuration) tries to locate them using name node specified by the name-node element, but later during job submission it expects this path to be under the default Oozie name node - Processing of the job-xml element if job xml is specified via absolute path. Oozie tries locate it under the default Oozie name node instead of the name-node specified in action. Specifying non-default name node makes a lot of sense in Azure environment, because it allows to submit the same job to different Hadoop clusters. I will submit a fix for CR soon. Please refer attached short document for more information. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OOZIE-1685) Oozie doesn’t process correctly workflows with a non-default name node
[ https://issues.apache.org/jira/browse/OOZIE-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Zhitomirsky updated OOZIE-1685: Attachment: (was: oozie-1685_branch-3.3.patch) Oozie doesn’t process correctly workflows with a non-default name node -- Key: OOZIE-1685 URL: https://issues.apache.org/jira/browse/OOZIE-1685 Project: Oozie Issue Type: Bug Components: core Affects Versions: trunk, 3.3.2, 4.0.0 Environment: Any Reporter: Benjamin Zhitomirsky Fix For: trunk, 3.3.2, 4.0.0 Attachments: Design of the fix OOZIE-1685-rev1.docx, oozie-1685-trunk.patch Original Estimate: 168h Remaining Estimate: 168h When name-node element in Oozie workflow specifies a name node different from the default one (specified in core-site.xml), the following functionality doesn’t work properly: - Location of libraries specified via oozie.service.WorkflowAppService.system.libpath. Oozie first (during launcher configuration) tries to locate them using name node specified by the name-node element, but later during job submission it expects this path to be under the default Oozie name node - Processing of the job-xml element if job xml is specified via absolute path. Oozie tries locate it under the default Oozie name node instead of the name-node specified in action. Specifying non-default name node makes a lot of sense in Azure environment, because it allows to submit the same job to different Hadoop clusters. I will submit a fix for CR soon. Please refer attached short document for more information. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OOZIE-1685) Oozie doesn’t process correctly workflows with a non-default name node
[ https://issues.apache.org/jira/browse/OOZIE-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Zhitomirsky updated OOZIE-1685: Attachment: (was: Design of the fix OOZIE-1685.docx) Oozie doesn’t process correctly workflows with a non-default name node -- Key: OOZIE-1685 URL: https://issues.apache.org/jira/browse/OOZIE-1685 Project: Oozie Issue Type: Bug Components: core Affects Versions: trunk, 3.3.2, 4.0.0 Environment: Any Reporter: Benjamin Zhitomirsky Fix For: trunk, 3.3.2, 4.0.0 Attachments: Design of the fix OOZIE-1685-rev1.docx, oozie-1685-trunk.patch Original Estimate: 168h Remaining Estimate: 168h When name-node element in Oozie workflow specifies a name node different from the default one (specified in core-site.xml), the following functionality doesn’t work properly: - Location of libraries specified via oozie.service.WorkflowAppService.system.libpath. Oozie first (during launcher configuration) tries to locate them using name node specified by the name-node element, but later during job submission it expects this path to be under the default Oozie name node - Processing of the job-xml element if job xml is specified via absolute path. Oozie tries locate it under the default Oozie name node instead of the name-node specified in action. Specifying non-default name node makes a lot of sense in Azure environment, because it allows to submit the same job to different Hadoop clusters. I will submit a fix for CR soon. Please refer attached short document for more information. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OOZIE-1685) Oozie doesn’t process correctly workflows with a non-default name node
[ https://issues.apache.org/jira/browse/OOZIE-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Zhitomirsky updated OOZIE-1685: Attachment: (was: oozie-1685_branch-4.0.patch) Oozie doesn’t process correctly workflows with a non-default name node -- Key: OOZIE-1685 URL: https://issues.apache.org/jira/browse/OOZIE-1685 Project: Oozie Issue Type: Bug Components: core Affects Versions: trunk, 3.3.2, 4.0.0 Environment: Any Reporter: Benjamin Zhitomirsky Fix For: trunk, 3.3.2, 4.0.0 Attachments: Design of the fix OOZIE-1685-rev1.docx, oozie-1685-trunk.patch Original Estimate: 168h Remaining Estimate: 168h When name-node element in Oozie workflow specifies a name node different from the default one (specified in core-site.xml), the following functionality doesn’t work properly: - Location of libraries specified via oozie.service.WorkflowAppService.system.libpath. Oozie first (during launcher configuration) tries to locate them using name node specified by the name-node element, but later during job submission it expects this path to be under the default Oozie name node - Processing of the job-xml element if job xml is specified via absolute path. Oozie tries locate it under the default Oozie name node instead of the name-node specified in action. Specifying non-default name node makes a lot of sense in Azure environment, because it allows to submit the same job to different Hadoop clusters. I will submit a fix for CR soon. Please refer attached short document for more information. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OOZIE-1685) Oozie doesn’t process correctly workflows with a non-default name node
[ https://issues.apache.org/jira/browse/OOZIE-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Zhitomirsky updated OOZIE-1685: Attachment: oozie-1685-trunk.patch Oozie doesn’t process correctly workflows with a non-default name node -- Key: OOZIE-1685 URL: https://issues.apache.org/jira/browse/OOZIE-1685 Project: Oozie Issue Type: Bug Components: core Affects Versions: trunk, 3.3.2, 4.0.0 Environment: Any Reporter: Benjamin Zhitomirsky Fix For: trunk, 3.3.2, 4.0.0 Attachments: Design of the fix OOZIE-1685-rev1.docx, oozie-1685-trunk.patch Original Estimate: 168h Remaining Estimate: 168h When name-node element in Oozie workflow specifies a name node different from the default one (specified in core-site.xml), the following functionality doesn’t work properly: - Location of libraries specified via oozie.service.WorkflowAppService.system.libpath. Oozie first (during launcher configuration) tries to locate them using name node specified by the name-node element, but later during job submission it expects this path to be under the default Oozie name node - Processing of the job-xml element if job xml is specified via absolute path. Oozie tries locate it under the default Oozie name node instead of the name-node specified in action. Specifying non-default name node makes a lot of sense in Azure environment, because it allows to submit the same job to different Hadoop clusters. I will submit a fix for CR soon. Please refer attached short document for more information. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OOZIE-1685) Oozie doesn’t process correctly workflows with a non-default name node
[ https://issues.apache.org/jira/browse/OOZIE-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Zhitomirsky updated OOZIE-1685: Attachment: (was: oozie-1685-trunk.patch) Oozie doesn’t process correctly workflows with a non-default name node -- Key: OOZIE-1685 URL: https://issues.apache.org/jira/browse/OOZIE-1685 Project: Oozie Issue Type: Bug Components: core Affects Versions: trunk, 3.3.2, 4.0.0 Environment: Any Reporter: Benjamin Zhitomirsky Fix For: trunk, 3.3.2, 4.0.0 Attachments: Design of the fix OOZIE-1685-rev1.docx, oozie-1685-trunk.patch Original Estimate: 168h Remaining Estimate: 168h When name-node element in Oozie workflow specifies a name node different from the default one (specified in core-site.xml), the following functionality doesn’t work properly: - Location of libraries specified via oozie.service.WorkflowAppService.system.libpath. Oozie first (during launcher configuration) tries to locate them using name node specified by the name-node element, but later during job submission it expects this path to be under the default Oozie name node - Processing of the job-xml element if job xml is specified via absolute path. Oozie tries locate it under the default Oozie name node instead of the name-node specified in action. Specifying non-default name node makes a lot of sense in Azure environment, because it allows to submit the same job to different Hadoop clusters. I will submit a fix for CR soon. Please refer attached short document for more information. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OOZIE-1685) Oozie doesn’t process correctly workflows with a non-default name node
[ https://issues.apache.org/jira/browse/OOZIE-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Zhitomirsky updated OOZIE-1685: Fix Version/s: (was: 4.0.0) (was: 3.3.2) Oozie doesn’t process correctly workflows with a non-default name node -- Key: OOZIE-1685 URL: https://issues.apache.org/jira/browse/OOZIE-1685 Project: Oozie Issue Type: Bug Components: core Affects Versions: trunk, 3.3.2, 4.0.0 Environment: Any Reporter: Benjamin Zhitomirsky Fix For: trunk Attachments: Design of the fix OOZIE-1685-rev1.docx, oozie-1685-trunk.patch Original Estimate: 168h Remaining Estimate: 168h When name-node element in Oozie workflow specifies a name node different from the default one (specified in core-site.xml), the following functionality doesn’t work properly: - Location of libraries specified via oozie.service.WorkflowAppService.system.libpath. Oozie first (during launcher configuration) tries to locate them using name node specified by the name-node element, but later during job submission it expects this path to be under the default Oozie name node - Processing of the job-xml element if job xml is specified via absolute path. Oozie tries locate it under the default Oozie name node instead of the name-node specified in action. Specifying non-default name node makes a lot of sense in Azure environment, because it allows to submit the same job to different Hadoop clusters. I will submit a fix for CR soon. Please refer attached short document for more information. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OOZIE-1685) Oozie doesn’t process correctly workflows with a non-default name node
[ https://issues.apache.org/jira/browse/OOZIE-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Zhitomirsky updated OOZIE-1685: Attachment: Design of the fix OOZIE-1685.docx Details of the issue and proposed fix Oozie doesn’t process correctly workflows with a non-default name node -- Key: OOZIE-1685 URL: https://issues.apache.org/jira/browse/OOZIE-1685 Project: Oozie Issue Type: Bug Components: core Affects Versions: 3.3.2, 4.0.0 Environment: Any Reporter: Benjamin Zhitomirsky Fix For: 3.3.2 Attachments: Design of the fix OOZIE-1685.docx Original Estimate: 168h Remaining Estimate: 168h When name-node element in Oozie workflow specifies a name node different from the default one (specified in core-site.xml), the following functionality doesn’t work properly: - Location of libraries specified via oozie.service.WorkflowAppService.system.libpath. Oozie first (during launcher configuration) tries to locate them using name node specified by the name-node element, but later during job submission it expects this path to be under the default Oozie name node - Processing of the job-xml element if job xml is specified via absolute path. Oozie tries locate it under the default Oozie name node instead of the name-node specified in action. Specifying non-default name node makes a lot of sense in Azure environment, because it allows to submit the same job to different Hadoop clusters. I will submit a fix for CR soon. Please refer attached short document for more information. -- This message was sent by Atlassian JIRA (v6.1.5#6160)