hadoop-yarn-issues mailing list archives

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

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

Haibo Chen commented on YARN-4985:

Uploading a patch for preliminary review. The hbase-backend module has been split into two
separate modules based on the versions of hadoop-common/hdfs/auth that they need to run under.
Coprocessor code and code in hbase-tests are now in the same module, that is, *timelineservice-hbase-server,
which depends on *timelineservice-hbase-client that includes all table schema and hbase code
executed in YARN trunk. YARN-6094 has enabled dynamic loading of coprocessor from HDFS, now
if coprocessor code lives in a hbase-server jar that depends on hbase-client jar, I don't
think the dynamic loading from HDFS will work unless HBase somehow knows how to pull in the
dependent jars. Thoughts on workaround, [~sjlee0]? In the meantime, I will continue to verify
maven dependencies to make sure they are clean.

> 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