hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-6418) Regression: DFS_NAMENODE_USER_NAME_KEY missing in trunk
Date Sun, 29 Jun 2014 12:06:24 GMT

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

Steve Loughran commented on HDFS-6418:
--------------------------------------

bq. In the long term, Slider should eliminate referencing DFSConfigKeys. In the short term,
I don't mind adding back the previously removed constants as deprecated. Sounds good?

I could eliminate the references -but think that if I used the constants, others would too.
I just found it first as I do try to build my code against trunk regularly

There's no equivalent in HDFS of the public constants offered by Common and YARN. We need
something similar with the public stable constant strings; this private-tagged interface could
extend it. Moving the constants would be simple matter of then deciding what is public, what
is private and pulling up the public ones.

> 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
>            Assignee: Tsz Wo Nicholas Sze
>         Attachments: h6418_20140619.patch
>
>
> 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
(v6.2#6252)

Mime
View raw message