[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16690185#comment-16690185 ] Chen Liang commented on HDFS-14017: --- I've committed v014 patch to feature branch, thanks for all the reviews and discussions! > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Fix For: HDFS-12943 > > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch, HDFS-14017-HDFS-12943.008.patch, > HDFS-14017-HDFS-12943.009.patch, HDFS-14017-HDFS-12943.010.patch, > HDFS-14017-HDFS-12943.011.patch, HDFS-14017-HDFS-12943.012.patch, > HDFS-14017-HDFS-12943.013.patch, HDFS-14017-HDFS-12943.014.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16690170#comment-16690170 ] Chen Liang commented on HDFS-14017: --- Thanks for looking into this [~xkrogen]! I agree that there should be no way the patch was breaking things, as it is changing a class not currently being used anywhere, just like you mentioned. I checked with Konstantin as well, he is okay with committing it. I will commit soon. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch, HDFS-14017-HDFS-12943.008.patch, > HDFS-14017-HDFS-12943.009.patch, HDFS-14017-HDFS-12943.010.patch, > HDFS-14017-HDFS-12943.011.patch, HDFS-14017-HDFS-12943.012.patch, > HDFS-14017-HDFS-12943.013.patch, HDFS-14017-HDFS-12943.014.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689892#comment-16689892 ] Erik Krogen commented on HDFS-14017: Even stranger now: This time around it claims that everything passed, but it only ran 84 tests, whereas it should be around 6000+. Even more strange, it doesn't report that it is skipping them, it seems to think those 6000 tests don't exist... Not sure where to go from here. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch, HDFS-14017-HDFS-12943.008.patch, > HDFS-14017-HDFS-12943.009.patch, HDFS-14017-HDFS-12943.010.patch, > HDFS-14017-HDFS-12943.011.patch, HDFS-14017-HDFS-12943.012.patch, > HDFS-14017-HDFS-12943.013.patch, HDFS-14017-HDFS-12943.014.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689855#comment-16689855 ] Hadoop QA commented on HDFS-14017: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 18s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} HDFS-12943 Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 18m 35s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 41s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 25s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 41s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 12m 3s{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 37s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 25s{color} | {color:green} HDFS-12943 passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 39s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 33s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 16s{color} | {color:green} hadoop-hdfs-project/hadoop-hdfs-client: The patch generated 0 new + 28 unchanged - 3 fixed = 28 total (was 31) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 36s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 11m 20s{color} | {color:green} patch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 38s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 22s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 31s{color} | {color:green} hadoop-hdfs-client in the patch passed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 22s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 52m 24s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hadoop:8f97d6f | | JIRA Issue | HDFS-14017 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12948415/HDFS-14017-HDFS-12943.014.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle | | uname | Linux a38a4647757f 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | HDFS-12943 / e49fb63 | | maven | version: Apache Maven 3.3.9 | | Default Java | 1.8.0_181 | | findbugs | v3.1.0-RC1 | | Test Results | https://builds.apache.org/job/PreCommit-HDFS-Build/25547/testReport/ | | Max. process+thread count | 445 (vs. ulimit of 1) | | modules | C: hadoop-hdfs-project/hadoop-hdfs-client U: hadoop-hdfs-project/hadoop-hdfs-client | | Console output | https://builds.apache.org/job/PreCommit-HDFS-Bui
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689781#comment-16689781 ] Chen Liang commented on HDFS-14017: --- Hmmm...thanks for the checking [~xkrogen]! > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch, HDFS-14017-HDFS-12943.008.patch, > HDFS-14017-HDFS-12943.009.patch, HDFS-14017-HDFS-12943.010.patch, > HDFS-14017-HDFS-12943.011.patch, HDFS-14017-HDFS-12943.012.patch, > HDFS-14017-HDFS-12943.013.patch, HDFS-14017-HDFS-12943.014.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689764#comment-16689764 ] Erik Krogen commented on HDFS-14017: Hm.. Something is pretty wrong with Jenkins. It's not actually running any of the tests, failing with errors like: {code} [ERROR] ExecutionException The forked VM terminated without properly saying goodbye. VM crash or System.exit called? [ERROR] Command was /bin/sh -c cd /testptch/hadoop/hadoop-hdfs-project/hadoop-hdfs-client && /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -Xmx2048m -XX:+HeapDumpOnOutOfMemoryError -jar /testptch/hadoop/hadoop-hdfs-project/hadoop-hdfs-client/target/surefire/surefirebooter375579229167329239.jar /testptch/hadoop/hadoop-hdfs-project/hadoop-hdfs-client/target/surefire 2018-11-16T17-42-57_928-jvmRun1 surefire586051240617267363tmp surefire_07291752059438872666tmp [ERROR] Error occurred in starting fork, check output in log [ERROR] Process Exit Code: 1 {code} It looks like the last patch where it actually ran tests was v009. We were seeing the same issue on HDFS-14035, but I don't see it on other Jenkins runs against trunk (rather than the HDFS-12943 branch). [~chliang], I see you didn't merge in trunk after committing HDFS-14035, I'm going to do so now and then re-run Jenkins and see if things get better. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch, HDFS-14017-HDFS-12943.008.patch, > HDFS-14017-HDFS-12943.009.patch, HDFS-14017-HDFS-12943.010.patch, > HDFS-14017-HDFS-12943.011.patch, HDFS-14017-HDFS-12943.012.patch, > HDFS-14017-HDFS-12943.013.patch, HDFS-14017-HDFS-12943.014.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689747#comment-16689747 ] Hadoop QA commented on HDFS-14017: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 20s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} HDFS-12943 Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 18m 13s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 36s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 22s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 40s{color} | {color:green} HDFS-12943 passed {color} | | {color:red}-1{color} | {color:red} shadedclient {color} | {color:red} 11m 11s{color} | {color:red} branch has errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 39s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s{color} | {color:green} HDFS-12943 passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 41s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 35s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 18s{color} | {color:green} hadoop-hdfs-project/hadoop-hdfs-client: The patch generated 0 new + 28 unchanged - 3 fixed = 28 total (was 31) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 37s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:red}-1{color} | {color:red} shadedclient {color} | {color:red} 11m 36s{color} | {color:red} patch has errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 43s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 25s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 40s{color} | {color:red} hadoop-hdfs-client in the patch failed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 25s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 51m 4s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hadoop:8f97d6f | | JIRA Issue | HDFS-14017 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12948415/HDFS-14017-HDFS-12943.014.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle | | uname | Linux 5155acbcb480 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | HDFS-12943 / 481b618 | | maven | version: Apache Maven 3.3.9 | | Default Java | 1.8.0_181 | | findbugs | v3.1.0-RC1 | | unit | https://builds.apache.org/job/PreCommit-HDFS-Build/25546/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs-client.txt | | Test Results | https://builds.apache.org/job/PreCommit-HDFS-Build/25546/testReport/ | | Max. process+thread count | 107 (vs. ulimit of 1) | | modules | C: hadoop-hdfs-project/hadoop-hdfs-client U: ha
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688877#comment-16688877 ] Hadoop QA commented on HDFS-14017: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 14s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} HDFS-12943 Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 22m 50s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 36s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 20s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 41s{color} | {color:green} HDFS-12943 passed {color} | | {color:red}-1{color} | {color:red} shadedclient {color} | {color:red} 11m 17s{color} | {color:red} branch has errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 36s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s{color} | {color:green} HDFS-12943 passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 39s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 33s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 16s{color} | {color:green} hadoop-hdfs-project/hadoop-hdfs-client: The patch generated 0 new + 29 unchanged - 3 fixed = 29 total (was 32) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 37s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 1s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:red}-1{color} | {color:red} shadedclient {color} | {color:red} 11m 6s{color} | {color:red} patch has errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 38s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 25s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 41s{color} | {color:red} hadoop-hdfs-client in the patch failed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 24s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 55m 44s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hadoop:8f97d6f | | JIRA Issue | HDFS-14017 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12948415/HDFS-14017-HDFS-12943.014.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle | | uname | Linux 297ef8be536f 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | HDFS-12943 / 481b618 | | maven | version: Apache Maven 3.3.9 | | Default Java | 1.8.0_181 | | findbugs | v3.1.0-RC1 | | unit | https://builds.apache.org/job/PreCommit-HDFS-Build/25538/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs-client.txt | | Test Results | https://builds.apache.org/job/PreCommit-HDFS-Build/25538/testReport/ | | Max. process+thread count | 108 (vs. ulimit of 1) | | modules | C: hadoop-hdfs-project/hadoop-hdfs-client U: ha
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688867#comment-16688867 ] Konstantin Shvachko commented on HDFS-14017: Looks good: +1 on v014 > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch, HDFS-14017-HDFS-12943.008.patch, > HDFS-14017-HDFS-12943.009.patch, HDFS-14017-HDFS-12943.010.patch, > HDFS-14017-HDFS-12943.011.patch, HDFS-14017-HDFS-12943.012.patch, > HDFS-14017-HDFS-12943.013.patch, HDFS-14017-HDFS-12943.014.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688857#comment-16688857 ] Hadoop QA commented on HDFS-14017: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 16s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} HDFS-12943 Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 18m 42s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 41s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 22s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 43s{color} | {color:green} HDFS-12943 passed {color} | | {color:red}-1{color} | {color:red} shadedclient {color} | {color:red} 11m 18s{color} | {color:red} branch has errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 37s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s{color} | {color:green} HDFS-12943 passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 39s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 34s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 34s{color} | {color:green} the patch passed {color} | | {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange} 0m 15s{color} | {color:orange} hadoop-hdfs-project/hadoop-hdfs-client: The patch generated 9 new + 29 unchanged - 3 fixed = 38 total (was 32) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 37s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:red}-1{color} | {color:red} shadedclient {color} | {color:red} 10m 54s{color} | {color:red} patch has errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 37s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 22s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 40s{color} | {color:red} hadoop-hdfs-client in the patch failed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 21s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 50m 31s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hadoop:8f97d6f | | JIRA Issue | HDFS-14017 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12948414/HDFS-14017-HDFS-12943.013.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle | | uname | Linux e230853eb906 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | HDFS-12943 / 481b618 | | maven | version: Apache Maven 3.3.9 | | Default Java | 1.8.0_181 | | findbugs | v3.1.0-RC1 | | checkstyle | https://builds.apache.org/job/PreCommit-HDFS-Build/25537/artifact/out/diff-checkstyle-hadoop-hdfs-project_hadoop-hdfs-client.txt | | unit | https://builds.apache.org/job/PreCommit-HDFS-Build/25537/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs-client.txt | | Test Results | https://builds.apache.org/job/PreComm
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688837#comment-16688837 ] Chen Liang commented on HDFS-14017: --- Thanks for the catch, removed those imports in v014 patch > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch, HDFS-14017-HDFS-12943.008.patch, > HDFS-14017-HDFS-12943.009.patch, HDFS-14017-HDFS-12943.010.patch, > HDFS-14017-HDFS-12943.011.patch, HDFS-14017-HDFS-12943.012.patch, > HDFS-14017-HDFS-12943.013.patch, HDFS-14017-HDFS-12943.014.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688831#comment-16688831 ] Erik Krogen commented on HDFS-14017: You have a bunch of unused imports in ORPPWithIPFailover, but other than that, LGTM. +1 > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch, HDFS-14017-HDFS-12943.008.patch, > HDFS-14017-HDFS-12943.009.patch, HDFS-14017-HDFS-12943.010.patch, > HDFS-14017-HDFS-12943.011.patch, HDFS-14017-HDFS-12943.012.patch, > HDFS-14017-HDFS-12943.013.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688814#comment-16688814 ] Chen Liang commented on HDFS-14017: --- Thanks for the comments [~xkrogen]. Post v013 patch. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch, HDFS-14017-HDFS-12943.008.patch, > HDFS-14017-HDFS-12943.009.patch, HDFS-14017-HDFS-12943.010.patch, > HDFS-14017-HDFS-12943.011.patch, HDFS-14017-HDFS-12943.012.patch, > HDFS-14017-HDFS-12943.013.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688316#comment-16688316 ] Erik Krogen commented on HDFS-14017: Hey [~vagarychen], I think the new approach looks great! My comments are below. * {{DFS_CLIENT_FAILOVER_IPFAILOVER_VIRTUAL_ADDRESS}} should probably live within {{HdfsClientConfigKeys.Failover}}. Then it can also make use of {{Failover.PREFIX}}. * The change within {{ObserverReadProxyProvider}} is no longer necessary. * The Javadoc on the ORPPWithIPFailover constructor doesn't make sense, it says that IPFPP is the default for ORPP * {{ORPPWithIPFailover#getProxyAddresses}} is looking the same as {{AbstractNNFailoverProxyProvider}}, is there any reason that we need to override this? It seems that besides the new {{virtual-address}} config, the rest of the configuration between ORPP and ORPPWithIPFailover is the same, we should be able to just re-use this logic? > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch, HDFS-14017-HDFS-12943.008.patch, > HDFS-14017-HDFS-12943.009.patch, HDFS-14017-HDFS-12943.010.patch, > HDFS-14017-HDFS-12943.011.patch, HDFS-14017-HDFS-12943.012.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16687387#comment-16687387 ] Hadoop QA commented on HDFS-14017: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 14s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} HDFS-12943 Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 18m 17s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 19s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 40s{color} | {color:green} HDFS-12943 passed {color} | | {color:red}-1{color} | {color:red} shadedclient {color} | {color:red} 11m 8s{color} | {color:red} branch has errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 45s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s{color} | {color:green} HDFS-12943 passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 33s{color} | {color:red} hadoop-hdfs-client in the patch failed. {color} | | {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 32s{color} | {color:red} hadoop-hdfs-client in the patch failed. {color} | | {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 32s{color} | {color:red} hadoop-hdfs-client in the patch failed. {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 17s{color} | {color:green} hadoop-hdfs-project/hadoop-hdfs-client: The patch generated 0 new + 32 unchanged - 3 fixed = 32 total (was 35) {color} | | {color:red}-1{color} | {color:red} mvnsite {color} | {color:red} 0m 34s{color} | {color:red} hadoop-hdfs-client in the patch failed. {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:red}-1{color} | {color:red} shadedclient {color} | {color:red} 2m 16s{color} | {color:red} patch has errors when building and testing our client artifacts. {color} | | {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 16s{color} | {color:red} hadoop-hdfs-client in the patch failed. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 23s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 35s{color} | {color:red} hadoop-hdfs-client in the patch failed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 20s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 39m 45s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hadoop:8f97d6f | | JIRA Issue | HDFS-14017 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12948235/HDFS-14017-HDFS-12943.012.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle | | uname | Linux 6cd33639509d 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | HDFS-12943 / 481b618 | | maven | version: Apache Maven 3.3.9 | | Default Java | 1.8.0_181 | | findbugs | v3.1.0-RC1 | | mvninstall | https://builds.apache.org/job/PreCommit-HDFS-Build/25529/artifact/out/patch-mvninstall-hadoop-hdfs-project_hadoop-hdfs-client.txt | | compile | https://builds.apache.org/job/PreCommit-HDFS-Build/25529/artifact/out/patch-compile-hadoop-hdfs-project_hado
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16687354#comment-16687354 ] Chen Liang commented on HDFS-14017: --- Post v012 patch to change how ORFPPWithIP is configured. Now the defaultFS needs to be name service id, and an additional config key {{dfs.client.failover.ipfailover.virtual-address.}} is used to determine what is the virtual ip address for failover. I've tested from running hdfs commands, but still need to test for delegation token. Post for early review and Jenkins check. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch, HDFS-14017-HDFS-12943.008.patch, > HDFS-14017-HDFS-12943.009.patch, HDFS-14017-HDFS-12943.010.patch, > HDFS-14017-HDFS-12943.011.patch, HDFS-14017-HDFS-12943.012.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16687006#comment-16687006 ] Hadoop QA commented on HDFS-14017: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 16s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} HDFS-12943 Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 20m 12s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 41s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 22s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 43s{color} | {color:green} HDFS-12943 passed {color} | | {color:red}-1{color} | {color:red} shadedclient {color} | {color:red} 11m 51s{color} | {color:red} branch has errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 36s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s{color} | {color:green} HDFS-12943 passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 41s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 35s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 18s{color} | {color:green} hadoop-hdfs-project/hadoop-hdfs-client: The patch generated 0 new + 4 unchanged - 3 fixed = 4 total (was 7) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 40s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:red}-1{color} | {color:red} shadedclient {color} | {color:red} 11m 57s{color} | {color:red} patch has errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 42s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 44s{color} | {color:red} hadoop-hdfs-client in the patch failed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 26s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 54m 22s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hadoop:8f97d6f | | JIRA Issue | HDFS-14017 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12948191/HDFS-14017-HDFS-12943.011.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle | | uname | Linux f1821418cc4d 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | HDFS-12943 / 8b5277f | | maven | version: Apache Maven 3.3.9 | | Default Java | 1.8.0_181 | | findbugs | v3.1.0-RC1 | | unit | https://builds.apache.org/job/PreCommit-HDFS-Build/25524/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs-client.txt | | Test Results | https://builds.apache.org/job/PreCommit-HDFS-Build/25524/testReport/ | | Max. process+thread count | 97 (vs. ulimit of 1) | | modules | C: hadoop-hdfs-project/hadoop-hdfs-client U: hadoop
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16686936#comment-16686936 ] Chen Liang commented on HDFS-14017: --- v011 patch to fix checkstyle issues. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch, HDFS-14017-HDFS-12943.008.patch, > HDFS-14017-HDFS-12943.009.patch, HDFS-14017-HDFS-12943.010.patch, > HDFS-14017-HDFS-12943.011.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16685997#comment-16685997 ] Hadoop QA commented on HDFS-14017: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 15s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 1s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} HDFS-12943 Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 23m 44s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 19s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 42s{color} | {color:green} HDFS-12943 passed {color} | | {color:red}-1{color} | {color:red} shadedclient {color} | {color:red} 11m 26s{color} | {color:red} branch has errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 43s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 27s{color} | {color:green} HDFS-12943 passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 42s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 35s{color} | {color:green} the patch passed {color} | | {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange} 0m 16s{color} | {color:orange} hadoop-hdfs-project/hadoop-hdfs-client: The patch generated 9 new + 4 unchanged - 3 fixed = 13 total (was 7) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 38s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:red}-1{color} | {color:red} shadedclient {color} | {color:red} 11m 31s{color} | {color:red} patch has errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 48s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 22s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 49s{color} | {color:red} hadoop-hdfs-client in the patch failed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 27s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 56m 52s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hadoop:8f97d6f | | JIRA Issue | HDFS-14017 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12948029/HDFS-14017-HDFS-12943.010.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle | | uname | Linux 4676290b7fac 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | HDFS-12943 / 8b5277f | | maven | version: Apache Maven 3.3.9 | | Default Java | 1.8.0_181 | | findbugs | v3.1.0-RC1 | | checkstyle | https://builds.apache.org/job/PreCommit-HDFS-Build/25513/artifact/out/diff-checkstyle-hadoop-hdfs-project_hadoop-hdfs-client.txt | | unit | https://builds.apache.org/job/PreCommit-HDFS-Build/25513/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs-client.txt | | Test Results | https://builds.apache.org/job/PreCommit
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16685962#comment-16685962 ] Konstantin Shvachko commented on HDFS-14017: For the record, my assumptions in the comment above were incorrect based on my recent evaluation of the state of the art. Here is how IPFailoverPP is configured: {code:java} // Client uses only these two lines from core-site.xml fs.defaultFS = virtual-address-nn.in.com:8020 dfs.client.failover.proxy.provider.virtual-address-nn.in.com = o.a.h...IPFailoverProxyProvider // Standard HA configuration for the NameNode in hdfs-site-xml dfs.nameservices = my-cluster dfs.ha.namenodes.my-cluster = nn1, nn2 dfs.namenode.rpc-address.my-cluster.nn1 = physical-address-ha1.in.com:8020 dfs.namenode.rpc-address.my-cluster.nn2 = physical-address-ha2.in.com:8020 {code} >From HDFS-6334 I understand IPFPP was intentionally made to look like it talks >to a single node. Which looks hacky now. We have multiple NameNodes and the >Proxy provider is in control which NN it should direct the call, so using NN's >logical name (aka nameserviceID) seems the right way for newly developed proxy >providers. We should still support current way for IPFPP for backward >compatibility, so be it. For ORPPwithIPF we still need to know virtual address for NameNode failover. I suggest we add a new parameter for that, adding it to the config above: {code:java} dfs.client.failover.ipfailover.virtual-address.my-cluster = virtual-address-nn.in.com:8020 {code} So the ORPP part will use {{dfs.nameservices}} to obtain physical addresses of NNs, and the IPF part will instantiate IPFPP based on {{dfs.client.failover.ipfailover.virtual-address}} parameter. And we can still support traditional IPFPP (without Observer) using current {{core-site.xml}} configuration. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch, HDFS-14017-HDFS-12943.008.patch, > HDFS-14017-HDFS-12943.009.patch, HDFS-14017-HDFS-12943.010.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16685861#comment-16685861 ] Hadoop QA commented on HDFS-14017: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 16s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} HDFS-12943 Compile Tests {color} || | {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 7m 47s{color} | {color:red} root in HDFS-12943 failed. {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 19s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 38s{color} | {color:green} HDFS-12943 passed {color} | | {color:red}-1{color} | {color:red} shadedclient {color} | {color:red} 12m 55s{color} | {color:red} branch has errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 41s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 27s{color} | {color:green} HDFS-12943 passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 43s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 37s{color} | {color:green} the patch passed {color} | | {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange} 0m 17s{color} | {color:orange} hadoop-hdfs-project/hadoop-hdfs-client: The patch generated 9 new + 3 unchanged - 3 fixed = 12 total (was 6) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 39s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:red}-1{color} | {color:red} shadedclient {color} | {color:red} 11m 23s{color} | {color:red} patch has errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 41s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 25s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 43s{color} | {color:red} hadoop-hdfs-client in the patch failed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 27s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 42m 3s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hadoop:8f97d6f | | JIRA Issue | HDFS-14017 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12948029/HDFS-14017-HDFS-12943.010.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle | | uname | Linux 36c18075 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | HDFS-12943 / 8b5277f | | maven | version: Apache Maven 3.3.9 | | Default Java | 1.8.0_181 | | mvninstall | https://builds.apache.org/job/PreCommit-HDFS-Build/25508/artifact/out/branch-mvninstall-root.txt | | findbugs | v3.1.0-RC1 | | checkstyle | https://builds.apache.org/job/PreCommit-HDFS-Build/25508/artifact/out/diff-checkstyle-hadoop-hdfs-project_hadoop-hdfs-client.txt | | unit | https://builds.apache.org/job/PreCommit-HDFS-Build/25508/artifact/ou
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16685811#comment-16685811 ] Chen Liang commented on HDFS-14017: --- Thanks for the the detailed suggestions and post sharing [~xkrogen]! Post v010 patch. Will file another JIRA for follow up. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch, HDFS-14017-HDFS-12943.008.patch, > HDFS-14017-HDFS-12943.009.patch, HDFS-14017-HDFS-12943.010.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16685603#comment-16685603 ] Erik Krogen commented on HDFS-14017: Hey [~vagarychen], v009 patch LGTM as long as we have a follow-on JIRA to sort out the federation issues and reduce reliance on assumptions about the nameservices available. My only comments are regarding the Javadoc on ORPPWithIPF. The expanded Javadoc is great and I appreciate the example of how to configure it but could be improved a little: * There are a few typos: "virtal address", "stanby" * "Extends ObserverReadProxyProvider" -> Link ORPP here? * For the list, I would prefer to see proper HTML {{}}, {{}} tags * For the in-line {{}} tags, using Javadoc version with {{@code}} would be better * For the {{}} block used for the configs, I think {{}} would be more applicable here. I think [this post|https://reflectoring.io/howto-format-code-snippets-in-javadoc/] has a really good breakdown of the different options of how to format code in Javadoc. Oh, also, you have a star-import in ORPPWithIPF that shouldn't be there. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch, HDFS-14017-HDFS-12943.008.patch, > HDFS-14017-HDFS-12943.009.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16684658#comment-16684658 ] Hadoop QA commented on HDFS-14017: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 31s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} HDFS-12943 Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 22m 41s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 45s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 25s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 54s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 14m 38s{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 53s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 36s{color} | {color:green} HDFS-12943 passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 48s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 46s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 46s{color} | {color:green} the patch passed {color} | | {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange} 0m 21s{color} | {color:orange} hadoop-hdfs-project/hadoop-hdfs-client: The patch generated 10 new + 3 unchanged - 3 fixed = 13 total (was 6) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 48s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 14m 24s{color} | {color:green} patch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 59s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 29s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 39s{color} | {color:green} hadoop-hdfs-client in the patch passed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 32s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 64m 54s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hadoop:8f97d6f | | JIRA Issue | HDFS-14017 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12947928/HDFS-14017-HDFS-12943.009.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle | | uname | Linux 614a7ac5efb0 3.13.0-153-generic #203-Ubuntu SMP Thu Jun 14 08:52:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | HDFS-12943 / 8b5277f | | maven | version: Apache Maven 3.3.9 | | Default Java | 1.8.0_181 | | findbugs | v3.1.0-RC1 | | checkstyle | https://builds.apache.org/job/PreCommit-HDFS-Build/25497/artifact/out/diff-checkstyle-hadoop-hdfs-project_hadoop-hdfs-client.txt | | Test Results | https://builds.apache.org/job/PreCommit-HDFS-Build/25497/testReport/ | | Max. process+thread count | 307 (vs. ulimit of 1) | | modules | C:
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16684614#comment-16684614 ] Chen Liang commented on HDFS-14017: --- Post v009 patch. Had some offline discussion with [~shv] and [~xkrogen]. The main point of v009 patch is that is mainly to not to use all the configured physical address, but only physical addresses of one arbitrary name services. If there is only one though, there is no difference. Ideally we would like to resolve the inconsistency of virtual IP and name services, and behave more reasonable in federation, we still needs to come up with a plan for that. This is only meant to be the current temporary solution. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch, HDFS-14017-HDFS-12943.008.patch, > HDFS-14017-HDFS-12943.009.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16682588#comment-16682588 ] Konstantin Shvachko commented on HDFS-14017: I meant nameserviceID, rather than namespace. Here is an example: {code:java} dfs.nameservices = virtual-address-nn.g.li.com dfs.ha.namenodes.virtual-address-nn.g.li.com = nn1, nn2 dfs.namenode.rpc-address.virtual-address-nn.g.li.com.nn1 = physical-address-ha1.g.li.com dfs.namenode.rpc-address.virtual-address-nn.g.li.com.nn2 = physical-address-ha2.g.li.com {code} Here {{virtual-address-nn.g.li.com}} plays the role of the nameserviceID, which turns out to be the virtual address of NN. Does your patch works with that configuration? We should really unit test this. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch, HDFS-14017-HDFS-12943.008.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16682168#comment-16682168 ] Chen Liang commented on HDFS-14017: --- Thanks for sharing [~shv]. What did you mean by "the virtual address of the NameName in current IFPP comes from the namespaceID"? How's that different from the current patch? maybe an example? And yes, current IPProxy does not care about physical addresses, that's the whole point of it. But in observer read, then are to we able to talk to different NNs without knowing physical addresses, or are we only talking about the failover part here? cc. [~xkrogen] > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch, HDFS-14017-HDFS-12943.008.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16682145#comment-16682145 ] Konstantin Shvachko commented on HDFS-14017: Had an offline discussion with Erik. The gist of the problem is that the virtual address of the NameName in current IFPP comes from the namespaceID, and it doesn't look further into physical addresses of the NameNodes. So if we want to keep this behavior, we should do the same for ORPPWithIPF. I suggest that we double-check this is the case. If so, Erik says it is, let's go this route, even though it seems hacky, but let's finally document this properly. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch, HDFS-14017-HDFS-12943.008.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680819#comment-16680819 ] Hadoop QA commented on HDFS-14017: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 19s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} HDFS-12943 Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 20m 10s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 41s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 22s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 43s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 13m 10s{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 33s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s{color} | {color:green} HDFS-12943 passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 42s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 36s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 36s{color} | {color:green} the patch passed {color} | | {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange} 0m 18s{color} | {color:orange} hadoop-hdfs-project/hadoop-hdfs-client: The patch generated 10 new + 3 unchanged - 3 fixed = 13 total (was 6) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 38s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 13m 10s{color} | {color:green} patch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 41s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 25s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 33s{color} | {color:green} hadoop-hdfs-client in the patch passed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 24s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 57m 30s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hadoop:8f97d6f | | JIRA Issue | HDFS-14017 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12947517/HDFS-14017-HDFS-12943.008.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle | | uname | Linux 1d2c1d23a86b 3.13.0-153-generic #203-Ubuntu SMP Thu Jun 14 08:52:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | HDFS-12943 / 8b5277f | | maven | version: Apache Maven 3.3.9 | | Default Java | 1.8.0_181 | | findbugs | v3.1.0-RC1 | | checkstyle | https://builds.apache.org/job/PreCommit-HDFS-Build/25473/artifact/out/diff-checkstyle-hadoop-hdfs-project_hadoop-hdfs-client.txt | | Test Results | https://builds.apache.org/job/PreCommit-HDFS-Build/25473/testReport/ | | Max. process+thread count | 339 (vs. ulimit of 1) | | modules | C:
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680779#comment-16680779 ] Chen Liang commented on HDFS-14017: --- Updated Javadoc in v008 patch, thanks [~shv] for the offline discussion. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch, HDFS-14017-HDFS-12943.008.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680758#comment-16680758 ] Chen Liang commented on HDFS-14017: --- The URI here is passed from {{NameNodeProxiesClient#createFailoverProxyProvider}} which can be further traced up to from places such as DFSClient. Which, most of time, is likely gonna be the URI from fs.defaultFS. That's all I meant to say... The original statement was just mentioning a potential way to leverage. This was not meant to be an absolute judgement, and yes, it can be reconfigured to other address passed in. Sorry for the miscommunication. But still, whatever the URI is, the URI is passed to the IPFailover failover proxy, to serve as the address for failover proxy address. In current patch, the only place that actually really uses {{fs.defaultFS}} is one place, which is getNameServiceAddress (DFSUtilClient.getAddresses call) so that when it failed to find any configured physical addresses, it took the defaultFS as the last hope. I also considered maybe this is probably an error case, but I think both ways can be argued. This is also why changing fs.defaultFS client still works, because the difference only in failover. I agree that current approach is not ideal and absolutely agree with {{only NameNodes that are relevant to this specific nameservice ID}}. This is only temporary and still with TODOs. I have been trying to make this point the whole time... When there is only one nameservice ID, no other choice anyway. But when there are multiple nameservices, the question here is not we need to find the right NNs of a given nameservice, how do we even determine *which nameservice* to look up. I don't think we have a full picture about supporting federation yet, there are known places that need to be revisited as well e.g. how does ViewFS work here. I can think of ways but that would be a separate JIRA. So even we support multiple nameservices here, it's not adding any value and likely is subject to changes in future. The purpose here is not to get it perfect, but only as a current temporary solution with target of supporting one nameservice only. I did have considered locating the right NameNodes since the beginning (that's why the TODO has been there since first patch). It was just it is not yet clear how that should happen without a full picture of interaction with Federation at all. When we sort it out, we surely should come back and revisit this. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680534#comment-16680534 ] Erik Krogen commented on HDFS-14017: {quote}Probably should be based on different fs.defaultFS, which is what IPFailover is largely relying on, maybe only a subset should be checked. {quote} I disagree that IPFPP is relying on {{fs.defaultFS}}. We clearly see from this snippet that it loads the NN address of the provided URI, which may or may not be the default. I don't see anywhere that IPFPP accesses the {{fs.defaultFS}}. {code:java|title=IPFailoverProxyProvider} public IPFailoverProxyProvider(Configuration conf, URI uri, Class xface, HAProxyFactory factory) { super(conf, uri, xface, factory); this.nnProxyInfo = new NNProxyInfo(DFSUtilClient.getNNAddress(uri)); } {code} {quote}In fact, in current patch, the call to DFSUtilClient.getAddresses(...) is already getting ALL the host physical addresses for ALL the nameservices. All these addresses will have proxies created and DT cloned. The issue I had was that, it may not be true that all these addresses should be considered (and clone DT for) in case of federation. {quote} Hm, I see your point now that, if you make the assumption that there is only one nameservice considered, you can then assume that all of the configured NameNodes are part of that nameservice. I still don't think that is the right approach... We should be using {{DFSUtilClient.getAddressesForNameserviceId()}}, which takes in a nameservice ID, to return only NameNodes that are relevant to _this_ specific nameservice ID. The nameservice ID can be determined by just {{nameNodeURI.getHost()}} – the same convention followed by {{NameNodeProxiesClient.getFailoverProxyProviderClass()}} to load the correct proxy provider for the nameservice. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680370#comment-16680370 ] Konstantin Shvachko commented on HDFS-14017: The patch looks good. Really liked all changes are concentrated inside ORPPWithIPF class. Minor things: # Log messages should avoid string concatenation for performance, e.g.: {{LOG.debug("Adding new proxy with address {}", isa)}} # JavaDoc for ORPPWithIPF class should be revised. Particularly it should explicitly say how address for IPFailover is configured, and that the rest of the namenodes are setup as in regular HA config. Let's also include an example of a config. # JavaDoc for the constructor is confusing. # We also need some tests for ORPPWithIPF. I am fine doing it in a followup jira. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679188#comment-16679188 ] Chen Liang commented on HDFS-14017: --- Had some offline discussion with [~shv]. Turns out we can further refactor/simplify the code to remove {{initializeNameNodeProxies()}} but directly overwrite {{AbstractNNFailoverProxyProvider#getProxyAddresses}}. Also fixed a unnecessary suppress annotation, and renamed {{getConfiguredAddress}} method as suggested. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch, > HDFS-14017-HDFS-12943.006.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679248#comment-16679248 ] Hadoop QA commented on HDFS-14017: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 20s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} HDFS-12943 Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 21m 0s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 44s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 30s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 56s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 13m 41s{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 34s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s{color} | {color:green} HDFS-12943 passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 43s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 36s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 36s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 18s{color} | {color:green} hadoop-hdfs-project/hadoop-hdfs-client: The patch generated 0 new + 3 unchanged - 3 fixed = 3 total (was 6) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 37s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 13m 18s{color} | {color:green} patch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 41s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 25s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 33s{color} | {color:green} hadoop-hdfs-client in the patch passed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 24s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 59m 0s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hadoop:8f97d6f | | JIRA Issue | HDFS-14017 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12947330/HDFS-14017-HDFS-12943.006.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle | | uname | Linux 7a42cd3bd92a 3.13.0-153-generic #203-Ubuntu SMP Thu Jun 14 08:52:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | HDFS-12943 / 8b5277f | | maven | version: Apache Maven 3.3.9 | | Default Java | 1.8.0_181 | | findbugs | v3.1.0-RC1 | | Test Results | https://builds.apache.org/job/PreCommit-HDFS-Build/25464/testReport/ | | Max. process+thread count | 306 (vs. ulimit of 1) | | modules | C: hadoop-hdfs-project/hadoop-hdfs-client U: hadoop-hdfs-project/hadoop-hdfs-client | | Console output | https://builds.apache.org/job/PreCommit-HDFS-Buil
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16678668#comment-16678668 ] Chen Liang commented on HDFS-14017: --- Hmm...I don't see it does not work, as long as both nn1 and nn2 shows up in {{dfs.namenode.rpc-address.\*.\*}} configs, there will be two proxies created, and client should be able to find them. I did a quick in the test cluster, seem to worked, although it was checking from command line and won't tell about DT. I agree that with all the {{dfs.namenode.rpc-address}} configs we have all information. In fact, in current patch, the call to {{DFSUtilClient.getAddresses(...)}} is already getting ALL the host physical addresses for ALL the nameservices. All these addresses will have proxies created and DT cloned. The issue I had was that, it may not be true that all these addresses should be considered (and clone DT for) in case of federation. Probably should be based on different {{fs.defaultFS}}, which is what IPFailover is largely relying on, maybe only a subset should be checked. This is what I meant by the need to tie fs.defaultFS to some name service/physical address. And this, needs to be answered under the context of how IPFailover should work with Federation. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16678626#comment-16678626 ] Erik Krogen commented on HDFS-14017: {quote} What did you by a non-default FS? I meant the config fs.defaultFS, shouldn't it always be there? {quote} I mean something like: {code} hdfs dfs -Dfs.defaultFS=hdfs://nn1:8020 -ls / vs. hdfs dfs -Dfs.defaultFS=hdfs://nn1:8020 -ls hdfs://nn2:8020/ {code} In both cases the default FS points to nn1, but in the second the proxy provider should be created pointing at nn2. I don't think the current approach will work for the second case, but please correct me if I am wrong. {quote} I think dfs.namenode.rpc-address. values are not VIP but actual addresses {quote} Sorry, I meant {{dfs.namenode.rpc-address.}}. Agreed that {{dfs.namenode.rpc-address..}} contains physical hostnames. To address your broader point, I don't think we should change any of the behavior of the way {{IPFailoverPP}} is configured today and what is required, but I don't think we need to restrict ourselves from the possibility of adding/enforcing configurations when using {{ORPPWithIPFailover}}. If {{dfs.namenode.rpc-address.}} contains the VIP and {{dfs.namenode.rpc-address..}} contains the physical hostnames, I think that should be all necessary information. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16678601#comment-16678601 ] Chen Liang commented on HDFS-14017: --- What did you by a non-default FS? I meant the config fs.defaultFS, shouldn't it always be there? I think {{dfs.namenode.rpc-address.}} values are not VIP but actual addresses, this was partly the reason I started making change to {{ObserverReadProxyProviderWithIPFailover}}. Currently the code only checks {{dfs.namenode.rpc-address.*}} configs when defaultFS is determined a logic URI, which is not the case for IPFailover, changing this seemed to affect many places if I remember correctly (at least many tests will fail). In configured setup, fs.defaultFS is a nameservice, and code will automatically replace nnID as in {{dfs.namenode.rpc-address.}} with that fs.defaultFS nameservice id. In IPFailover case, fs.defaultFS is not logical so {{dfs.namenode.rpc-address.*}} are ignored completely. In our environment, there is configured address for nameservice (which are for Datanodes). This is where I needed to tie them together. Also, I have been trying to not explicitly match URIs because VIP can be anything in theory. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16678570#comment-16678570 ] Erik Krogen commented on HDFS-14017: Interesting... I see the issue now. I did not notice previously that you were relying on the default FS via {{DFSUtilClient.getNNAddress(conf)}}. Actually, IIRC, even in a non-federated environment, this won't work if a user specifies a non-default FS. You should be able to extract the correct value from {{dfs.namenode.rpc-address.}}, which contains the VIP, at least in our configurations (I can't seem to find {{IPFailoverPP}} configuration documented anywhere... the [HA documentation|https://hadoop.apache.org/docs/r3.1.1/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html] doesn't even mention it as a valid proxy provider). You can then match this against the URI provided to the constructor to determine what name service this proxy provider belongs to, and use that to determine the correct physical hostnames. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16677550#comment-16677550 ] Hadoop QA commented on HDFS-14017: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 12s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} HDFS-12943 Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 23m 23s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 41s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 25s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 47s{color} | {color:green} HDFS-12943 passed {color} | | {color:red}-1{color} | {color:red} shadedclient {color} | {color:red} 11m 59s{color} | {color:red} branch has errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 38s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 32s{color} | {color:green} HDFS-12943 passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 43s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 36s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 36s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 18s{color} | {color:green} hadoop-hdfs-project/hadoop-hdfs-client: The patch generated 0 new + 3 unchanged - 3 fixed = 3 total (was 6) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 40s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:red}-1{color} | {color:red} shadedclient {color} | {color:red} 11m 49s{color} | {color:red} patch has errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 43s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 44s{color} | {color:red} hadoop-hdfs-client in the patch failed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 27s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 57m 34s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hadoop:8f97d6f | | JIRA Issue | HDFS-14017 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12947159/HDFS-14017-HDFS-12943.005.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle | | uname | Linux 25ed6131bbfa 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | HDFS-12943 / 8b5277f | | maven | version: Apache Maven 3.3.9 | | Default Java | 1.8.0_181 | | findbugs | v3.1.0-RC1 | | unit | https://builds.apache.org/job/PreCommit-HDFS-Build/25455/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs-client.txt | | Test Results | https://builds.apache.org/job/PreCommit-HDFS-Build/25455/testReport/ | | Max. process+thread count | 99 (vs. ulimit of 1) | | modules | C: hadoop-hdfs-project/hadoop-hdfs-client U: hadoop
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16677496#comment-16677496 ] Chen Liang commented on HDFS-14017: --- Thanks for the review [~xkrogen]! Post v005 patch. bq. Seems like there is some duplication... Thanks for the suggestion! Made the change as you suggested. bq. Do you have a plan to The keys in {{addressList}} are name service names. So the question I had here was that when there are multiple name services, which delegation token should the client clone for each name service / how client can tie the VIP to the different name services. I think it would be more clear after we have a more holistic idea on how Observer read clients interact with multiple name services. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16677392#comment-16677392 ] Erik Krogen commented on HDFS-14017: * Can we extend the Javadoc of {{ObserverReadProxyProviderWithIPFailover}} to explain the logic more fully (CFPP/ORPP-like behavior for the observers, IPFPP-like behavior for the active)? * Seems like there is some duplication between the two {{initializeProxy}} methods. The main difference is just how {{nameNodeProxies}} is constructed. How about the following, which I think makes it more clear what the actual differences are: ** We have a {{initializeNameNodeProxies()}} method that is overridden in ORPPWithIPFailover. ** The fields you made {{protected}} can go back to being {{private}} ** The shared logic can be in ORPP ** I think {{cloneDelegationTokenForHA()}} can occur within the overridden {{initializeNameNodeProxies()}} ? * Shouldn't use star import in ORPPWithIPFailover * Do you have a plan to solve the TODO in {{ORPPWithIPFailover#getConfiguredAddresses()}}? It seems that the key in the {{addressList}} map should be able to be used to solve this? > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16677303#comment-16677303 ] Hadoop QA commented on HDFS-14017: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 18s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} HDFS-12943 Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 22m 6s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 45s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 24s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 51s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 13m 28s{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 38s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 29s{color} | {color:green} HDFS-12943 passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 43s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 36s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 36s{color} | {color:green} the patch passed {color} | | {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange} 0m 19s{color} | {color:orange} hadoop-hdfs-project/hadoop-hdfs-client: The patch generated 4 new + 3 unchanged - 3 fixed = 7 total (was 6) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 45s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 13m 10s{color} | {color:green} patch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 50s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 40s{color} | {color:green} hadoop-hdfs-client in the patch passed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 26s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 60m 21s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hadoop:8f97d6f | | JIRA Issue | HDFS-14017 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12947122/HDFS-14017-HDFS-12943.004.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle | | uname | Linux f3c2acd3d1ab 3.13.0-153-generic #203-Ubuntu SMP Thu Jun 14 08:52:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | HDFS-12943 / 8b5277f | | maven | version: Apache Maven 3.3.9 | | Default Java | 1.8.0_181 | | findbugs | v3.1.0-RC1 | | checkstyle | https://builds.apache.org/job/PreCommit-HDFS-Build/25449/artifact/out/diff-checkstyle-hadoop-hdfs-project_hadoop-hdfs-client.txt | | Test Results | https://builds.apache.org/job/PreCommit-HDFS-Build/25449/testReport/ | | Max. process+thread count | 305 (vs. ulimit of 1) | | modules | C: h
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16677256#comment-16677256 ] Chen Liang commented on HDFS-14017: --- Thanks for the review [~shv]! Post v004 patch bq. 1. Main question if... This is exactly v003 patch was for :) , have chatted offline as well. bq. 2. Not sure why changes... You are right. Since this is no longer needed since v003, I removed those changes. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch, > HDFS-14017-HDFS-12943.004.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16676068#comment-16676068 ] Konstantin Shvachko commented on HDFS-14017: Checked v002 patch. # Main question if we could simplify this by assuming that the first address in the list of configured NNs corresponds to the Active? I don't think we should do the discovery of Active for IPFailover. Suppose that by mistake somebody transitions a wrong NN to active. It will be discovered by ORPP and the cluster will start fine, but then it wont failover correctly when needed. # Not sure why changes in {{ConfiguredFailoverProxyProvider}}. We must use {{addressKey}} in getProxyAddresses() instead of {{HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY}}. Otherwise it breaks {{InMemoryAliasMapFailoverProxyProvider}}. # Should not import {{SecurityUtil.*}}. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16675989#comment-16675989 ] Hadoop QA commented on HDFS-14017: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 15s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} HDFS-12943 Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 20m 50s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 40s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 23s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 43s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 13m 1s{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 38s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 27s{color} | {color:green} HDFS-12943 passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 41s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 35s{color} | {color:green} the patch passed {color} | | {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange} 0m 17s{color} | {color:orange} hadoop-hdfs-project/hadoop-hdfs-client: The patch generated 6 new + 4 unchanged - 4 fixed = 10 total (was 8) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 39s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 13m 1s{color} | {color:green} patch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 40s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 34s{color} | {color:green} hadoop-hdfs-client in the patch passed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 24s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 57m 55s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hadoop:8f97d6f | | JIRA Issue | HDFS-14017 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12946991/HDFS-14017-HDFS-12943.003.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle | | uname | Linux 82296ccd02ac 3.13.0-143-generic #192-Ubuntu SMP Tue Feb 27 10:45:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | HDFS-12943 / 8b5277f | | maven | version: Apache Maven 3.3.9 | | Default Java | 1.8.0_181 | | findbugs | v3.1.0-RC1 | | checkstyle | https://builds.apache.org/job/PreCommit-HDFS-Build/25442/artifact/out/diff-checkstyle-hadoop-hdfs-project_hadoop-hdfs-client.txt | | Test Results | https://builds.apache.org/job/PreCommit-HDFS-Build/25442/testReport/ | | Max. process+thread count | 341 (vs. ulimit of 1) | | modules | C:
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16675932#comment-16675932 ] Chen Liang commented on HDFS-14017: --- Post v003 patch based on the discussions above. Basically the only difference is that the failover proxy variable is set to be created by IPFailoverProxyProvider. This means when client fails to read from all observers, it fall backs to IPFailoverProxy, which maps to a VIP in cluster. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch, HDFS-14017-HDFS-12943.003.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16675536#comment-16675536 ] Chen Liang commented on HDFS-14017: --- [~xkrogen] yes, exactly, :) but yeah, the current patch can be confusing and there may still be places that need to be revisited, working on that. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16673720#comment-16673720 ] Erik Krogen commented on HDFS-14017: Okay, gotcha. I think I was confused by the mismatch of what your idea was and what was in the code :) It sounds like your end-result proposal is the same as mine: {{failoverProxy}} within ORPP will continue to point to the VIP always, but outside of this, we load all of the physical NN addresses for the purposes of DT cloning and scanning to find observer nodes. Is that right? > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16673712#comment-16673712 ] Chen Liang commented on HDFS-14017: --- Thanks for the clarification [~xkrogen]. bq. when the active changes, how will it ever start using the new active? My thought was that, just like how current IPFailover works now, it simply assumes the VIP is pointing to ANN, changing the VIP to NN mapping happens outside of HDFS. So I was thinking of the same approach, in IPFailover, just assume the VIP is the savior when failure happens (i.e. let failoverproxy variable point to VIP always), and don't bother to figure out what exactly it is pointing to. Although the current patch may not doing this correctly/have this at all. bq. we would need to introduce additional VIPs for observers, and it's not clear to me if this makes sense Can't agree more, exactly the struggle I had! The intuition of IPFailover is to rely on VIPs and don't bother figure out the physical addresses, but when there are multiple NNs, with some being observer and some being active. I was not sure how that is going to look like. So decided to go (for now at least) IPFailover sending request to discover physical nodes by itself. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16673670#comment-16673670 ] Erik Krogen commented on HDFS-14017: So the way I see it, ObserverReadProxyProvider has two responsibilities: (A) find the correct active, and (B) find the correct observer. CFPP-based ORPP does both (A) and (B) by scanning through all NNs. IPFailoverPP, however, does (A) without any scanning--we should maintain this behavior. Only for (B) should ORPPWithIPFailover scan, because we don't have a good way to discover the observers without scanning (we would need to introduce additional VIPs for observers, and it's not clear to me if this makes sense). Reducing ORPPWithIPFailover's ability to do (A) without scanning reduces its usefulness, and essentially just introduces a way to have a CFPP whose configuration looks like an IPFailoverPP. {quote}Despite it is becoming very similar to ObserverReadProxyProvider, I think there is still a very important difference, which is performFailover method. The failoverproxy variable decides when everything failed, what to do. For ConfiguredFailover, it automatically tries other NNs, while in IPFailover, it should not change. (still missing this change in the patch though). {quote} If IPFailover uses the NN addresses directly rather than the VIP, to perform failover, it will have to use a new proxy in the same way CFPP does. Otherwise, when the active changes, how will it ever start using the new active? {quote} The configuration of parsing configured addresses is mainly to address the delegation token. It needs to know all the addresses for delegation to work. And I don't know if it is really hacky {quote} It was mainly the comment about not supporting federation that concerned me, but looking more closely I think that is just a shortcoming of the current patch because you didn't handle it yet, not a fundamental problem. So I'll take back the hacky comment, I think I jumped to conclusions there. {quote}So my take was that if we could already leverage existing configuration, why do we need additional ones for the full set of NNs. {quote} Agree with this, I misunderstood the configuration parsing a bit, and it seems that we can successfully get all of the NNs from the IPFailoverPP configs. Great! Overall, I think your methodology for fetching all of the NN addresses actually makes sense, but then this should only be used for finding the observer / cloning DTs, and let the IPFailoverPP continue to function as normal (using VIP). > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16673575#comment-16673575 ] Chen Liang commented on HDFS-14017: --- Or, I guess I might not interpret the second correctly. Were you proposing having statically configured Active and Observer for ALL NNs in config for IPFailover? [~xkrogen] > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16673561#comment-16673561 ] Chen Liang commented on HDFS-14017: --- Thanks for the comment [~xkrogen]. Indeed a large part is like ObserverReadProxyProvider. We need the functionality of trying out different NNs, knowing which physical one is Observer, which physical one is Active. This demand is already not current IPFailover is able to do (I was trying to make this point in earlier comment too). IPFailover is no longer agnostic to which NN is active, it has actually knowingly talking to it when needed. For this to happen, it needs to get all the addresses from config. The part it becomes complex is that, IPFailover should determine who is active based on config, but IPFailover is able to figure out which one is actually the current active, should it change the base of assumption it has. What I meant to do here, is just to add the ability of reaching out to NNs and figure out their HA status to IPFailover. Despite it is becoming very similar to ObserverReadProxyProvider, I think there is still a very important difference, which is performFailover method. The failoverproxy variable decides when everything failed, what to do. For ConfiguredFailover, it automatically tries other NNs, while in IPFailover, it should not change. (still missing this change in the patch though). The configuration of parsing configured addresses is mainly to address the delegation token. It needs to know all the addresses for delegation to work. And I don't know if it is really hacky, because most of the logic is already happening elsewhere in ConfiguredFailover. e.g. it has almost the same logic of parsing configured addresses and clone delegation token to it. I almost just used the same methods. So my take was that if we could already leverage existing configuration, why do we need additional ones for the full set of NNs. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16673267#comment-16673267 ] Erik Krogen commented on HDFS-14017: Hey [~vagarychen], as I understand it, this patch essentially removes all IPFailover-based functionality like automatically going to active rather than searching for it. You've explicitly replaced the IPFailoverProxyProvider with a version of a ConfiguredFailoverProxyProvider. It's basically just an ObserverReadProxyProvider, but loading its configs in a hacky manner instead of specifying them correctly. I can't see any situation in which it would be better to use this PP than the existing ORPP. Please let me know if I'm missing anything here, though. I think the right way to handle this is to continue using IPFailoverPP for the active, but add a way to _additionally_ configure the full set of NameNodes for the ORPPWithIPFailover to use. This maintains as much existing functionality as possible, and only falls back to the scanning mechanism for new functionality. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch, > HDFS-14017-HDFS-12943.002.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16672542#comment-16672542 ] Hadoop QA commented on HDFS-14017: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 13s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} HDFS-12943 Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 25m 17s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 43s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 24s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 45s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 12m 50s{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 48s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s{color} | {color:green} HDFS-12943 passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 43s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 36s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 36s{color} | {color:green} the patch passed {color} | | {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange} 0m 18s{color} | {color:orange} hadoop-hdfs-project/hadoop-hdfs-client: The patch generated 7 new + 3 unchanged - 4 fixed = 10 total (was 7) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 40s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 13m 1s{color} | {color:green} patch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 0s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 43s{color} | {color:green} hadoop-hdfs-client in the patch passed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 26s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 62m 59s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hadoop:8f97d6f | | JIRA Issue | HDFS-14017 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12946630/HDFS-14017-HDFS-12943.002.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle | | uname | Linux 4147af7aae0e 4.4.0-134-generic #160~14.04.1-Ubuntu SMP Fri Aug 17 11:07:07 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | HDFS-12943 / 8b5277f | | maven | version: Apache Maven 3.3.9 | | Default Java | 1.8.0_181 | | findbugs | v3.1.0-RC1 | | checkstyle | https://builds.apache.org/job/PreCommit-HDFS-Build/25413/artifact/out/diff-checkstyle-hadoop-hdfs-project_hadoop-hdfs-client.txt | | Test Results | https://builds.apache.org/job/PreCommit-HDFS-Build/25413/testReport/ | | Max. process+thread count | 335 (vs. ulimit of 1) | | module
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16672388#comment-16672388 ] Chen Liang commented on HDFS-14017: --- Post the wrong patch...will update with v002 patch > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16672316#comment-16672316 ] Hadoop QA commented on HDFS-14017: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 28s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} HDFS-12943 Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 22m 27s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 43s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 23s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 45s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 13m 4s{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 39s{color} | {color:green} HDFS-12943 passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 29s{color} | {color:green} HDFS-12943 passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 44s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 39s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 39s{color} | {color:green} the patch passed {color} | | {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange} 0m 19s{color} | {color:orange} hadoop-hdfs-project/hadoop-hdfs-client: The patch generated 5 new + 1 unchanged - 2 fixed = 6 total (was 3) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 45s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 15m 5s{color} | {color:green} patch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 2s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 53s{color} | {color:green} hadoop-hdfs-client in the patch passed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 29s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 63m 18s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hadoop:8f97d6f | | JIRA Issue | HDFS-14017 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12946591/HDFS-14017-HDFS-12943.001.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle | | uname | Linux 2025ed919964 3.13.0-153-generic #203-Ubuntu SMP Thu Jun 14 08:52:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | HDFS-12943 / 8b5277f | | maven | version: Apache Maven 3.3.9 | | Default Java | 1.8.0_181 | | findbugs | v3.1.0-RC1 | | checkstyle | https://builds.apache.org/job/PreCommit-HDFS-Build/25411/artifact/out/diff-checkstyle-hadoop-hdfs-project_hadoop-hdfs-client.txt | | Test Results | https://builds.apache.org/job/PreCommit-HDFS-Build/25411/testReport/ | | Max. process+thread count | 307 (vs. ulimit of 1) | | modules | C: h
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16672008#comment-16672008 ] Chen Liang commented on HDFS-14017: --- Post v001 patch. The patch is to address two things: 1. To work with IPFailover proxy provider. Basically, to address the two issues mentioned in the description part. The key issue is that in IPFailover, currently, client is only aware of the virtual IP. But with Observer read, the client needs to know all the NN addresses, so client can no longer only use defaultFS, but needs to check for all configured RPC addresses. 2. To work with delegation token. Both NN only issue DT with the virtual IP, in current IPFailover, since client only talks to the virtual IP, so this is fine. But in Observer read, when client actually tries to reach to a NN, it will be looking for DT with the physical address of that particular NN, causing the client to skip the DT it was given (which has the virtual IP). The solution in the patch, is the same as how current ConfiguredFailoverProxy works, it clones the DT of the virtual address to all the other configured addresses. On a side note, with this change, ObserverReadProxyProviderWithIPFailover works in a very similar way as Configured failover, (again, because Observer read client will look for physical addresses of all NNs, which is already not IPFailover is for), only that it works with IPFailover configurations. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > Attachments: HDFS-14017-HDFS-12943.001.patch > > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code:java} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. > > A second issue closely related is about delegation token. For example, in > current IPFailover setup, say we have a virtual host nn.xyz.com, which points > to either of two physical nodes nn1.xyz.com or nn2.xyz.com. In current HDFS, > there is always only one DT being exchanged, which has hostname nn.xyz.com. > Server only issues this DT, and client only knows the host nn.xyz.com, so all > is good. But in Observer read, even with IPFailover, the client will no > longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and > nn2.xyz.com. During this process, current code will look for DT associated > with hostname nn1.xyz.com or nn2.xyz.com, which is different from the DT > given by NN. causing Token authentication to fail. This happens in > {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy > provider will need to resolve this as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
[ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663299#comment-16663299 ] Konstantin Shvachko commented on HDFS-14017: This about honoring HA configuration. Updated the description. > ObserverReadProxyProviderWithIPFailover should work with HA configuration > - > > Key: HDFS-14017 > URL: https://issues.apache.org/jira/browse/HDFS-14017 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Chen Liang >Assignee: Chen Liang >Priority: Major > > Currently {{ObserverReadProxyProviderWithIPFailover}} extends > {{ObserverReadProxyProvider}}, and the only difference is changing the proxy > factory to use {{IPFailoverProxyProvider}}. However this is not enough > because when calling constructor of {{ObserverReadProxyProvider}} in > super(...), the follow line: > {code} > nameNodeProxies = getProxyAddresses(uri, > HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY); > {code} > will try to resolve the all configured NN addresses to do configured > failover. But in the case of IPFailover, this does not really apply. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org