hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Nauroth (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HDFS-7359) NameNode in secured HA cluster fails to start if dfs.namenode.secondary.http-address cannot be interpreted as a network address.
Date Wed, 05 Nov 2014 18:34:34 GMT

     [ https://issues.apache.org/jira/browse/HDFS-7359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Chris Nauroth updated HDFS-7359:
--------------------------------
    Attachment: HDFS-7359.2.patch

Here is patch v2.  We need one more change in {{ImageServlet}} to prevent the problem from
happening during bootstrapStandby.

bq. It looks to me that simply removing the checks is equivalent to the current proposed patch,
correct?

bq. Removing that several lines means we no longer recognize SNN as a valid requestor. I guess
in some scenario (maybe even in the future) we can still allow SNN to download journals from
JN.

Thanks for reviewing, Haohui and Jing.  Right, doing it this way preserves existing behavior
if anyone out there is trying to use the SNN as requestor.  It would be a little odd to do
this, and I haven't seen it in practice, but I think it would be a backwards-incompatible
change if we dropped it.

Jing, are you still +1 for the v2 patch (pending fresh Jenkins run)?

> NameNode in secured HA cluster fails to start if dfs.namenode.secondary.http-address
cannot be interpreted as a network address.
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HDFS-7359
>                 URL: https://issues.apache.org/jira/browse/HDFS-7359
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: journal-node
>            Reporter: Chris Nauroth
>            Assignee: Chris Nauroth
>         Attachments: HDFS-7359.1.patch, HDFS-7359.2.patch
>
>
> In a secured cluster, the JournalNode validates that the caller is one of a valid set
of principals.  One of the principals considered is that of the SecondaryNameNode.  This involves
checking {{dfs.namenode.secondary.http-address}} and trying to interpret it as a network address.
 If a user has specified a value for this property that cannot be interpeted as a network
address, such as "null", then this causes the JournalNode operation to fail, and ultimately
the NameNode cannot start.  The JournalNode should not have a hard dependency on {{dfs.namenode.secondary.http-address}}
like this.  It is not typical to run a SecondaryNameNode in combination with JournalNodes.
 There is even a check in SecondaryNameNode that aborts if HA is enabled.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message