You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oozie.apache.org by "Hadoop QA (JIRA)" <ji...@apache.org> on 2016/07/28 06:19:20 UTC

[jira] [Commented] (OOZIE-2534) Versioned action libs (similar to how SharedLibs works)

    [ https://issues.apache.org/jira/browse/OOZIE-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15397007#comment-15397007 ] 

Hadoop QA commented on OOZIE-2534:
----------------------------------

Testing JIRA OOZIE-2534

Cleaning local git workspace

----------------------------

{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:green}+1 RAW_PATCH_ANALYSIS{color}
.    {color:green}+1{color} the patch does not introduce any @author tags
.    {color:green}+1{color} the patch does not introduce any tabs
.    {color:green}+1{color} the patch does not introduce any trailing spaces
.    {color:green}+1{color} the patch does not introduce any line longer than 132
.    {color:green}+1{color} the patch does adds/modifies 1 testcase(s)
{color:green}+1 RAT{color}
.    {color:green}+1{color} the patch does not seem to introduce new RAT warnings
{color:green}+1 JAVADOC{color}
.    {color:green}+1{color} the patch does not seem to introduce new Javadoc warnings
{color:red}-1 COMPILE{color}
.    {color:red}-1{color} HEAD does not compile
.    {color:red}-1{color} patch does not compile
.    {color:green}+1{color} the patch does not seem to introduce new javac warnings
{color:green}+1 BACKWARDS_COMPATIBILITY{color}
.    {color:green}+1{color} the patch does not change any JPA Entity/Colum/Basic/Lob/Transient annotations
.    {color:green}+1{color} the patch does not modify JPA files
{color:red}-1 TESTS{color}
.    Tests run: 1791
.    Tests failed: 1
.    Tests errors: 0

.    The patch failed the following testcases:

.      testNone(org.apache.oozie.command.coord.TestCoordActionInputCheckXCommandNonUTC)

{color:green}+1 DISTRO{color}
.    {color:green}+1{color} distro tarball builds with the patch 

----------------------------
{color:red}*-1 Overall result, please check the reported -1(s)*{color}


The full output of the test-patch run is available at

.   https://builds.apache.org/job/oozie-trunk-precommit-build/3115/

> Versioned action libs (similar to how SharedLibs works)
> -------------------------------------------------------
>
>                 Key: OOZIE-2534
>                 URL: https://issues.apache.org/jira/browse/OOZIE-2534
>             Project: Oozie
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 4.2.0
>            Reporter: Evgenij Kozhevnikov
>            Priority: Trivial
>         Attachments: versionedActionLibs.diff
>
>
> Case #1:
> Some projects uses lib folder near the workflow.xml in HDFS to put dependencies for the particular module. This jars often contains the version in name (example, some-internal-lib-1.2.3.jar). Before update the project you have to make sure that there are no RUNNING instances of the workflow, otherwise you risk to get an exception "JA008: File does not exist".
> Case #2:
> There are can be run some separate coordinators in Oozie with common sources in HDFS (with different properties). Some projects I've seen have more than 30 coordinators with common sources in HDFS. Some of them works daily, some hourly and another every 10 minutes. And even more these workflows can be called as subworkflows from another sources. It is very difficult to manage all this projects during updates. You have to suspend all dependees, make sure there are no any running instances and anyway you have to stop your cluster activities on this period, so after all the load on the cluster will increase.
> Solution:
> I suggest to have the same mechanism as sharedLibs, but for action libs. If actionLib contains any jars in the root they will be put on classpath as it were before. So the change will be backward compatible. But at the same time you can create a subdirectory with prefiix "lib_" and some timestamp or incremental version after that. JavaActionExecutor will take only the latest version subdirectory and put all artifacts from it to job cache.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)