[OOZIE-3056] Implement new mechanism to specify ShareLibs for workflow actions

• Type: New Feature
• Status: Closed
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: 5.0.0
• Fix Version/s: 5.0.0
• Component/s: core
• Assignee: Gézapeti
• Reporter: Attila Sasvári
• Created: 14/Sep/17 11:16
• Updated: 09/Apr/18 15:15
• Resolved: 26/Mar/18 12:51

Description

OOZIE-2687 introduces the launcher element for workflows:

<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>

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:

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.

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

Issue Links

• depends upon: OOZIE-2687 Create XML schema for launcher configurations
• links to: ReviewBoard