[
https://issues.apache.org/jira/browse/MAPREDUCE-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13138734#comment-13138734
]
Todd Lipcon commented on MAPREDUCE-3169:
----------------------------------------
I don't think we can feasibly update MiniMRCluster, since its constructors have
lots of MR1-isms. If we break the constructor APIs, then we can't have upstream
projects (eg HBase) compile against 20 and 23 interchangeably.
Just to make sure we're on the same page, here are the requirements as I see it:
1. Upstream projects must be able to start/stop a mini-cluster suitable for
testing MR jobs in a close-to-real-life environment.
2. When building against 0.20 they should start MR1 clusters, when building
against 0.23 they should start YARN/MR2 clusters.
3. Upstream projects should not be expected to move to any API that isn't
supported by 0.20 (lots of people will continue to run 0.20 for at least a year
if not longer)
4. Existing MR1 tests that don't depend on MR1 specifics should be updated to
run against MR2 in trunk/23.
Are we all agreed on the above?
The open questions are:
1. Should we repurpose the existing classes or create a new class?
2. Do we need to do changes to 0.20.x series to create a compatible API?
I'm not sure exactly what you mean by "Re-implement old MiniMRCluster to be a
facade on MiniMRClientCluster keeping only meaningful methods" -- but it seems
like you're suggesting API changes on MiniMRCluster in trunk. That would break
requirement #3 above.
> Create a new MiniMRCluster equivalent which only provides client APIs cross
> MR1 and MR2
> ---------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-3169
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-3169
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Components: mrv1, mrv2, test
> Affects Versions: 0.23.0
> Reporter: Todd Lipcon
> Assignee: Ahmed Radwan
> Attachments: MAPREDUCE-3169-0.20-security.patch,
> MAPREDUCE-3169-truck.patch
>
>
> Many dependent projects like HBase, Hive, Pig, etc, depend on MiniMRCluster
> for writing tests. Many users do as well. MiniMRCluster, however, exposes MR
> implementation details like the existence of TaskTrackers, JobTrackers, etc,
> since it was used by MR1 for testing the server implementations as well.
> This JIRA is to create a new interface which could be implemented either by
> MR1 or MR2 that exposes only the client-side portions of the MR framework.
> Ideally it would be "recompile-compatible" with MiniMRCluster for most
> applications, and the MR1 implementation could be backported to 20x branch.
> Thus, dependent projects like HBase could migrate to this implementation and
> test against both MR1 and MR2. We can also use this to port over the current
> functional tests that use only the client-side features of MiniMRCluster.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
