Details
-
Sub-task
-
Status: Closed
-
Critical
-
Resolution: Fixed
-
5.0.0
-
None
-
None
Description
It was possible to manipulate the MapperLauncher's environment through properties like:
- mapreduce.map.memory.mb
- mapreduce.map.cpu.vcores
- mapred.child.env
- mapred.child.java.opts
- mapred.job.queue.name - ability to set launcher queue
E.g. We were using mapred.child.env to pass SPARK_HOME to the LauncherMapper and make PySpark work.
Fixing OOZIE-2596 added a hack. We should decide how we support or break compatibility and how we allow the manipulation of the Launcher environment.
Verify if the new launcher section in global applies to actions in sub-workflows as well. It did not use to work before and was only fixed in OOZIE-2030. It would be good to have that testcase (TestSubWorkflowActionExecutor. testParentGlobalConf) updated with the new launcher section as well.
Attachments
Attachments
Issue Links
- blocks
-
OOZIE-2814 OYA: Update example workflows to newest schemas
- Closed
- is depended upon by
-
OOZIE-3056 Implement new mechanism to specify ShareLibs for workflow actions
- Closed
- relates to
-
OOZIE-3033 Extract workflow action XML schemas to separate xsd-s
- Open
-
OOZIE-3034 Allow setting default core/memory/queue for launcher per action type
- Open
- links to