hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sangjin Lee (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-4985) Refactor the coprocessor code & other definition classes into independent packages
Date Thu, 09 Feb 2017 20:28:41 GMT

    [ https://issues.apache.org/jira/browse/YARN-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860136#comment-15860136

Sangjin Lee commented on YARN-4985:

Thanks for refreshing my memory on this Haibo. Yes, I recall that was the main issue. To tease
out client and server correctly, we'd need a separate (common) module both client and server
depends on. The only way we could avoid it is if all the fine-grained downstream dependencies
can be isolated and moved into the hbase-server module. Do you know if it is feasible?

If that is not feasible, maybe this refactoring would be more problematic than beneficial.
What would we lose if we didn't do this refactoring? Also, if we didn't do this refactoring
and kept thins as is (just timelineservice-hbase), do we still have the dependency issues
in terms of installing the coprocessor (we need to follow all transitive dependencies between
classes)? If so, that needs to be addressed no matter what.

> Refactor the coprocessor code & other definition classes into independent packages
> ----------------------------------------------------------------------------------
>                 Key: YARN-4985
>                 URL: https://issues.apache.org/jira/browse/YARN-4985
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>            Reporter: Vrushali C
>            Assignee: Haibo Chen
>              Labels: YARN-5355
>         Attachments: YARN-4985-YARN-5355.prelim.patch
> As part of the coprocessor deployment, we have realized that it will be much cleaner
to have the coprocessor code sit in a package which does not depend on hadoop-yarn-server
classes. It only needs hbase and other util classes.
> These util classes and tag definition related classes can be refactored into their own
independent "definition" class package so that making changes to coprocessor code, upgrading
hbase, deploying hbase on a different hadoop version cluster etc all becomes operationally
much easier and less error prone to having different library jars etc.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org

View raw message