[jira] [Updated] (OOZIE-3056) Implement new mechanism to specify ShareLibs for workflow actions
[
https://issues.apache.org/jira/browse/OOZIE-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Cseh updated OOZIE-3056:
--
Attachment: OOZIE-3056.004.patch
> 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
>Assignee: Peter Cseh
>Priority: Critical
> Fix For: 5.0.0
>
> Attachments: OOZIE-3056.001.patch, OOZIE-3056.002.patch,
> OOZIE-3056.003.patch, OOZIE-3056.004.patch
>
>
> OOZIE-2687 introduces the {{launcher}} element for workflows:
> {code}
>
> 1024
> 1
> -Dsome.property=true -XX:+RandomJVMSwitch
> key=value
> root.oozie
> spark,hive
>
> {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 have priority over
> an action's , which has priority over the global section's
> and , 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
(v7.6.3#76005)
[jira] [Updated] (OOZIE-3056) Implement new mechanism to specify ShareLibs for workflow actions
[
https://issues.apache.org/jira/browse/OOZIE-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Cseh updated OOZIE-3056:
--
Attachment: OOZIE-3056.003.patch
> 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
>Assignee: Peter Cseh
>Priority: Critical
> Fix For: 5.0.0
>
> Attachments: OOZIE-3056.001.patch, OOZIE-3056.002.patch,
> OOZIE-3056.003.patch
>
>
> OOZIE-2687 introduces the {{launcher}} element for workflows:
> {code}
>
> 1024
> 1
> -Dsome.property=true -XX:+RandomJVMSwitch
> key=value
> root.oozie
> spark,hive
>
> {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 have priority over
> an action's , which has priority over the global section's
> and , 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
(v7.6.3#76005)
[jira] [Updated] (OOZIE-3056) Implement new mechanism to specify ShareLibs for workflow actions
[
https://issues.apache.org/jira/browse/OOZIE-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Cseh updated OOZIE-3056:
--
Attachment: OOZIE-3056.002.patch
> 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
>Assignee: Peter Cseh
>Priority: Critical
> Fix For: 5.0.0
>
> Attachments: OOZIE-3056.001.patch, OOZIE-3056.002.patch
>
>
> OOZIE-2687 introduces the {{launcher}} element for workflows:
> {code}
>
> 1024
> 1
> -Dsome.property=true -XX:+RandomJVMSwitch
> key=value
> root.oozie
> spark,hive
>
> {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 have priority over
> an action's , which has priority over the global section's
> and , 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
(v7.6.3#76005)
[jira] [Updated] (OOZIE-3056) Implement new mechanism to specify ShareLibs for workflow actions
[
https://issues.apache.org/jira/browse/OOZIE-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Cseh updated OOZIE-3056:
--
Priority: Critical (was: Major)
> 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
>Assignee: Peter Cseh
>Priority: Critical
> Fix For: 5.0.0
>
> Attachments: OOZIE-3056.001.patch
>
>
> OOZIE-2687 introduces the {{launcher}} element for workflows:
> {code}
>
> 1024
> 1
> -Dsome.property=true -XX:+RandomJVMSwitch
> key=value
> root.oozie
> spark,hive
>
> {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 have priority over
> an action's , which has priority over the global section's
> and , 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
(v7.6.3#76005)
[jira] [Updated] (OOZIE-3056) Implement new mechanism to specify ShareLibs for workflow actions
[
https://issues.apache.org/jira/browse/OOZIE-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Cseh updated OOZIE-3056:
--
Attachment: OOZIE-3056.001.patch
> 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
>Assignee: Peter Cseh
>Priority: Major
> Fix For: 5.0.0
>
> Attachments: OOZIE-3056.001.patch
>
>
> OOZIE-2687 introduces the {{launcher}} element for workflows:
> {code}
>
> 1024
> 1
> -Dsome.property=true -XX:+RandomJVMSwitch
> key=value
> root.oozie
> spark,hive
>
> {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 have priority over
> an action's , which has priority over the global section's
> and , 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
(v7.6.3#76005)
[jira] [Updated] (OOZIE-3056) Implement new mechanism to specify ShareLibs for workflow actions
[
https://issues.apache.org/jira/browse/OOZIE-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andras Piros updated OOZIE-3056:
Fix Version/s: 5.0.0
> 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
>Priority: Major
> Fix For: 5.0.0
>
>
> OOZIE-2687 introduces the {{launcher}} element for workflows:
> {code}
>
> 1024
> 1
> -Dsome.property=true -XX:+RandomJVMSwitch
> key=value
> root.oozie
> spark,hive
>
> {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 have priority over
> an action's , which has priority over the global section's
> and , 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
(v7.6.3#76005)
