You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oozie.apache.org by "Shwetha G S (JIRA)" <ji...@apache.org> on 2014/10/15 12:27:35 UTC

[jira] [Commented] (OOZIE-1789) Support backward compatibility of oozie share lib

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

Shwetha G S commented on OOZIE-1789:
------------------------------------

I will change ShareLibService.getLatestLibPath() to fall back to the base path if there are no timestamped directories. Purging of libraries at base path can't be done automatically as it can also contain timestamped directories. If required, we can address it in another jira. Sounds good?

> Support backward compatibility of oozie share lib
> -------------------------------------------------
>
>                 Key: OOZIE-1789
>                 URL: https://issues.apache.org/jira/browse/OOZIE-1789
>             Project: Oozie
>          Issue Type: Bug
>    Affects Versions: 3.1.3, 3.2.0, 3.3.0, 3.3.1, 3.3.2, 4.0.0, 4.0.1
>            Reporter: Satish Mittal
>            Assignee: Shwetha G S
>            Priority: Critical
>
> The current oozie trunk is not backward compatible with the way oozie share lib is configured. Till now, user would manually upload sharelib to HDFS at the system libpath, typically 
> {noformat}
> "/user/${user.name}/share/lib/" 
> {noformat}
> Whereas with latest oozie, one has to use "oozie-setup.sh sharelib create" command to first upload sharelib. 
> As a result, no one can run any actions if directly upgrading from 4.0 or before to the new version. There should be a way to support the older sharelib format in addition to the new format. This is needed for smooth upgrade to latest oozie.



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