Attila Sasvari created OOZIE-3056:
-------------------------------------
Summary: Implement new mechanism to specify ShareLibs for workflow
actions
Key: OOZIE-3056
URL: https://issues.apache.org/jira/browse/OOZIE-3056
Project: Oozie
Issue Type: New Feature
Components: core
Affects Versions: 5.0.0
Reporter: Attila Sasvari
OOZIE-2687 introduces the {{launcher}} element for workflows:
{code}
<launcher>
<memory>1024</memory>
<vcores>1</vcores>
<java-opts>-Dsome.property=true -XX:+RandomJVMSwitch</java-opts>
<env>key=value</env>
<queue>root.oozie</queue>
<sharelib>spark,hive</sharelib>
</launcher>
{code}
The purpose of this ticket is to discuss and implement new mechanism for
handling ShareLib.
{{addActionShareLib}} in {{JavaActionExecutor}} should adjusted. Regarding
"precedence order":
if global and an action level {{launcher}} and {{configuration}} (e.g.
{{oozie.action.sharelib.for.#ACTIONTYPE#}}) tries to override the sharelib the
following should apply:
{quote}
config properties defined in an action's <configuration> have priority over an
action's <job-xml>, which has priority over the global section's
<configuration> and <job-xml>, which has priority over the action defaults in
oozie-site, and so on.
{quote}
Here we have multiple choices how to handle sharelib:
- Alternative 1: override sharelib in a way that is consistent with current way
of handling Oozie configuration settings.
- Alternative 2: make sharelib additive
-- For example, if there is a global {{launcher}} with {{sharelib}} element in
a workflow that includes multiple ShareLibs (e.g. A,B), and
{{oozie.action.sharelib.for.#ACTIONTYPE#}} is also specified for an action's
configuration (e.g. C,D), then we take the union of the specified entities
(A,B,C,D would be included).
-- It's inconsistent with everything else
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
