[
https://issues.apache.org/jira/browse/OOZIE-2687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15706381#comment-15706381
]
Robert Kanter commented on OOZIE-2687:
--------------------------------------
+1 on mirroring Hadoop as much as possible.
A few more things we should think about in this area:
- The FS, Java, MR, and Pig actions are all defined in the workflow XSD.
Should we split these out into their own XSD files like the other actions?
Though it might be simplest to leave these here for compatibility.
- Do we want to keep using the 0.x schema version numbers? Or is now a good
opportunity to move them all to 1.0? Though that might imply that they're not
compatible with the older schemas, which isn't true; so maybe we should just
continue with the next 0.x?
- This is more of an implementation detail, but it would be better if we could
define the common complexTypes only once (e.g. {{<configuration>}},
{{<prepare>}}, etc) instead of redefining them in each XSD. I'm not sure if
there's a clean way to do that, but I think we should as long as it's
completely transparent to the user.
> 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)
