[
https://issues.apache.org/jira/browse/OOZIE-2687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126555#comment-16126555
]
Attila Sasvari commented on OOZIE-2687:
---------------------------------------
If we extract launcher / common properties to as separate xsd with
{{targetNamespace="uri:oozie:common:0.1}} then we will need to use a workflow
xml like:
{code}
<workflow-app xmlns="uri:oozie:workflow:0.6"
xmlns:common="uri:oozie:common:0.1" name="java-main-wf">
<global>
<common:launcher>
<common:memory>1024</common:memory>
<common:vcores>2</common:vcores>
<common:java-opts>dummyJavaOpts</common:java-opts>
<common:env>env1=value1:env2=value2</common:env>
<common:queue>dummyQueue</common:queue>
<common:sharelib>a,b,c</common:sharelib>
</common:launcher>
</global>
<start to="java-node"/>
<action name="java-node">
...
{code}
In other action definition, where we intend to include {{launcher}} properties,
the {{common}} prefix will be needed too. It is similar to the {{sla}} schema.
I can update LiteWorkflowAppParser in the next patch so that it uses the
namespace with the {{common}} prefix when dealing with launcher configuration
or we can create a new JIRA and implement common xsd extraction there after a
first working version that allows to specify queue, memory, vcores, java-opts,
etc for the launcher job.
> Create XML schema for launcher configurations
> ---------------------------------------------
>
> Key: OOZIE-2687
> URL: https://issues.apache.org/jira/browse/OOZIE-2687
> Project: Oozie
> Issue Type: Sub-task
> Affects Versions: 5.0.0
> Reporter: Peter Cseh
> Assignee: Attila Sasvari
> Priority: Critical
> Attachments: OOZIE-2687-001.patch
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
