[
https://issues.apache.org/jira/browse/OOZIE-2687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15708540#comment-15708540
]
Peter Bacsko commented on OOZIE-2687:
-------------------------------------
I agree with definining recurring compex types only once. That's my current
approach right now - I created a new {{oozie-common.xsd}} with a new namespace.
Then in the schemas, we can import this xsd and reference the types as
{{common:CONFIGURATION}} instead of {{workflow:CONFIGURATION}}. I haven't done
this yet, I've put only the new launcher type into the common xsd so far, but I
think it's reasonable to do this with those type which are defined multiple
times.
Btw shall I create a new xsd for each action + workflow with an increased
version number? How is it done in general?
> OYA: Figure out how to handle MR-specific properties
> ----------------------------------------------------
>
> Key: OOZIE-2687
> URL: https://issues.apache.org/jira/browse/OOZIE-2687
> Project: Oozie
> Issue Type: Sub-task
> Reporter: Peter Cseh
> Assignee: Peter Bacsko
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
