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 Tue, 11 Oct 2016 20:23:20 GMT

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

Haibo Chen commented on YARN-4985:
----------------------------------

[~vrushalic] Want to get your take on how we want to extract coprocessor code. IIUC, coprocessor
code is mostly self-contained except that it depends on ValueConverter, which is part of the
hbase table schema. Both the code run within yarn and the code run within hbase server depend
on the schema code. This makes me think that if there need to be three modules for ATSv2-hbase
code, hbase-backend-table-schema, hbase-backend-in-yarn and hbase-backend-in-hbase. And the
dependency will be like
hbase-backend-table-schema
+hbase-backend-in-yarn
+hbase-backend-in-hbase
The downside of this however, is the change will be non-trivial. Another question I had is
what about TimelineSchemaCreator. Is this also run in hbase server, thus, should sit along
with Coprocessor? Thoughts?

> 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: Vrushali C
>              Labels: YARN-5355
>
> 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
(v6.3.4#6332)

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


Mime
View raw message