hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars George (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-6275) Add conditional Hadoop properties assignment
Date Fri, 06 Jul 2012 13:22:34 GMT

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

Lars George commented on HBASE-6275:

Hey Ted, I thought about that as well, but that has some implications, the worst is that we
are using the old only in the code. Using both prepares us to use the new one once the old
is completely removed. But if others think that is OK for now, then I can change it. I was
tossing up either idea and went with the dual parameter approach.

This raises a larger question: how do we handle other parameters. Basically any Hadoop parameter
should be wrapped into the handleHadoopDeprecation() call, so that it is handled appropriately
for future versions. But if we have to handle a deprecation of an already replaced config
key (does that happen?) then using the oldest want work, and the one in between only works
with the previous and current version of hadoop.

Maybe we need to change the method to handleHadoopDeprecation(String[] keys) and call it like

handleHadoopDeprecation({ oldestKey, deprecatedKey, currentKey })

The question is, do we want to support three different version of Hadoop (different as in
changed config keys)?
> Add conditional Hadoop properties assignment
> --------------------------------------------
>                 Key: HBASE-6275
>                 URL: https://issues.apache.org/jira/browse/HBASE-6275
>             Project: HBase
>          Issue Type: Improvement
>          Components: client, master, regionserver
>    Affects Versions: 0.96.0
>            Reporter: Lars George
>            Assignee: Lars George
>            Priority: Minor
>             Fix For: 0.96.0
>         Attachments: HBASE-6275.patch
> See https://issues.apache.org/jira/browse/HBASE-3639, we should use VersionInfo to put
the proper one in, yet only one of them. Currently we always get this message when you start
a daemon or the shell:
> {noformat}2012-06-25 16:13:44,819 WARN org.apache.hadoop.conf.Configuration: fs.default.name
is deprecated. Instead, use fs.defaultFS{noformat}
> As well as this subsequently sporting the same issue:
> {noformat}2012-06-25 16:13:44,819 WARN org.apache.hadoop.conf.Configuration: mapred.task.id
is deprecated. Instead, use mapreduce.task.attempt.id{noformat}
> And the shell does:
> {noformat}12/06/25 16:05:26 WARN conf.Configuration: hadoop.native.lib is deprecated.
Instead, use io.native.lib.available{noformat}
> Talking to Stack he suggest:
> {quote}We should make a little function under util to do it because it will be
> reused in a bunch of places (in daemons, shell, out in scripts, etc).{quote}

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


View raw message