[
https://issues.apache.org/jira/browse/OOZIE-2687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16158472#comment-16158472
]
Attila Sasvari commented on OOZIE-2687:
---------------------------------------
I updated new schemas accordingly (using 1.0 as version number). Unfortunately
I could not find a easy/flexible way that allows to define and import "common"
schema without namespace prefixes ( {{<xs:any namespace="##other" minOccurs="1"
maxOccurs="1"/>}} is too permissive, it would allow to use any kind of
entities). Right now I set targetNamespace of {{oozie-common-1.0}} to
{{"uri:oozie:workflow:1.0"}} and use a reference to the launcher element with
{{<xs:element ref="workflow:launcher" minOccurs="0" maxOccurs="1"/>}} in
workflow action schemas. This way we can define a launcher element in the
following way:
{code}
...
<shell xmlns="uri:oozie:shell-action:1.0">
<job-tracker>${jobTracker}</job-tracker>
<name-node>${nameNode}</name-node>
<launcher xmlns=uri:oozie:workflow:1.0>
<memory.mb>1024</memory.mb>
</launcher>
...
{code}
I did not move CONFIGURATION, PREPARE, DELETE, and MKDIR into oozie-common.
Doing so would require workflows to define add an extra name space definition
for the element e.g. {{<configuration xmlns=uri:oozie:workflow:1.0>}}. I don't
think we want to do this.
Do you have some ideas that might help here?
> 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, OOZIE-2687-002.patch,
> OOZIE-2687-003.patch, OOZIE-2687-008.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)
