hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jing Zhao (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-6418) Regression: DFS_NAMENODE_USER_NAME_KEY missing in trunk
Date Tue, 17 Jun 2014 04:12:01 GMT

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

Jing Zhao commented on HDFS-6418:

bq. DFSConfigKeys becomes the public keyset (for compatibility)

Currently it feels like to me that a lot of keys defined in DFSConfigKeys should be private
to HDFS. If we want to expose some hdfs configuration keys as public to external projects,
maybe we should make DFSConfigKeys as private first, and gradually move those public keyset
to a new public ConfigKeys class.

> Regression: DFS_NAMENODE_USER_NAME_KEY missing in trunk
> -------------------------------------------------------
>                 Key: HDFS-6418
>                 URL: https://issues.apache.org/jira/browse/HDFS-6418
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: hdfs-client
>    Affects Versions: 3.0.0, 2.5.0
>            Reporter: Steve Loughran
> Code i have that compiles against HADOOP 2.4 doesn't build against trunk as someone took
away {{DFSConfigKeys.DFS_NAMENODE_USER_NAME_KEY}} -apparently in HDFS-6181.
> I know the name was obsolete, but anyone who has compiled code using that reference -rather
than cutting and pasting in the string- is going to find their code doesn't work.
> More subtly: that will lead to a link exception trying to run that code on a 2.5+  cluster.
> This is a regression: the old names need to go back in, even if they refer to the new
names and are marked as deprecated

This message was sent by Atlassian JIRA

View raw message