[
https://issues.apache.org/jira/browse/HADOOP-5919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715923#action_12715923
]
Hemanth Yamijala commented on HADOOP-5919:
------------------------------------------
In some more discussion, we found some problems in the proposed approach.
Primarily, two problems:
- If the list of deprecated configurations is centralized in the Configuration
class, what happens after project split ? So, if I have to deprecate a
configuration of mapred, should I submit a patch to core ? And since
theoretically they can have different release cycles, would that not conflict
with requirements of different projects.
- Another problem is that the mapping as proposed above seems simplistic for
some cases. For e.g. consider the split of number of slots into map slots and
reduce slots that happened a couple of releases back. If some change like that
needs to be supported, just setting the same value to both map slots and reduce
slots seems incorrect. A better mapping could be to split half of them into map
slots and half into reduce slots. In other words, it seems like we may need a
more complex mapping mechanism.
Given all these, I am thinking this should definitely be the subject on another
JIRA, as people might have more comments on the approach.
And since this bug is a blocker for 0.20.1, I suggest we do a mapping
specifically in the relevant classes for this bug (the memory related classes)
and move over to using a centralized framework for deprecating configurations
once the configuration JIRA is made available.
Does this make sense ?
> Memory management variables need a backwards compatibility option after
> HADOOP-5881
> -----------------------------------------------------------------------------------
>
> Key: HADOOP-5919
> URL: https://issues.apache.org/jira/browse/HADOOP-5919
> Project: Hadoop Core
> Issue Type: Bug
> Components: mapred
> Reporter: Hemanth Yamijala
> Assignee: rahul k singh
> Priority: Blocker
>
> HADOOP-5881 modified variables related to memory management without looking
> at the backwards compatibility angle. This JIRA is to adress the gap. Marking
> it a blocker for 0.20.1
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
