[jira] [Commented] (HDFS-15098) Add SM4 encryption method for HDFS
[ https://issues.apache.org/jira/browse/HDFS-15098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17151781#comment-17151781 ] Hadoop QA commented on HDFS-15098: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 25m 58s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} dupname {color} | {color:green} 0m 1s{color} | {color:green} No case conflicting files found. {color} | | {color:blue}0{color} | {color:blue} prototool {color} | {color:blue} 0m 0s{color} | {color:blue} prototool was not available. {color} | | {color:blue}0{color} | {color:blue} markdownlint {color} | {color:blue} 0m 0s{color} | {color:blue} markdownlint was not available. {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:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 0s{color} | {color:green} The patch appears to include 4 new or modified test files. {color} | || || || || {color:brown} trunk Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m 5s{color} | {color:blue} Maven dependency ordering for branch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 22m 3s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 17m 53s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m 55s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 3m 45s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 23m 0s{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 24s{color} | {color:green} trunk passed {color} | | {color:blue}0{color} | {color:blue} spotbugs {color} | {color:blue} 3m 20s{color} | {color:blue} Used deprecated FindBugs config; considering switching to SpotBugs. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 8m 23s{color} | {color:green} trunk passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 25s{color} | {color:blue} Maven dependency ordering for patch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m 56s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 18m 12s{color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} cc {color} | {color:red} 18m 12s{color} | {color:red} root generated 28 new + 134 unchanged - 28 fixed = 162 total (was 162) {color} | | {color:green}+1{color} | {color:green} golang {color} | {color:green} 18m 12s{color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} javac {color} | {color:red} 18m 12s{color} | {color:red} root generated 4 new + 1867 unchanged - 0 fixed = 1871 total (was 1867) {color} | | {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange} 2m 54s{color} | {color:orange} root: The patch generated 4 new + 228 unchanged - 5 fixed = 232 total (was 233) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 3m 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} xml {color} | {color:green} 0m 3s{color} | {color:green} The patch has no ill-formed XML file. {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 15m 34s{color} | {color:green} patch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 24s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 8m 16s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:red}-1{color} | {color:red} unit {color} | {color:red} 9m 35s{color} | {color:red} hadoop-common in the patch passed. {color} | | {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 18s{color} | {color:green} hadoop-hdfs-client in the
[jira] [Commented] (HDFS-15371) Nonstandard characters exist in NameNode.java
[ https://issues.apache.org/jira/browse/HDFS-15371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17151702#comment-17151702 ] Zhao Yi Ming commented on HDFS-15371: - [~jianghuazhu] already submitted a PR [GitHub Pull Request #2032|https://github.com/apache/hadoop/pull/2032] > Nonstandard characters exist in NameNode.java > - > > Key: HDFS-15371 > URL: https://issues.apache.org/jira/browse/HDFS-15371 > Project: Hadoop HDFS > Issue Type: Improvement >Affects Versions: 3.1.0 >Reporter: jianghua zhu >Assignee: Zhao Yi Ming >Priority: Minor > > In NameNode.Java, DFS_HA_ZKFC_PORT_KEY has non-standard characters behind it. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Updated] (HDFS-15098) Add SM4 encryption method for HDFS
[ https://issues.apache.org/jira/browse/HDFS-15098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zZtai updated HDFS-15098: - Attachment: HDFS-15098.008.patch Status: Patch Available (was: Open) > Add SM4 encryption method for HDFS > -- > > Key: HDFS-15098 > URL: https://issues.apache.org/jira/browse/HDFS-15098 > Project: Hadoop HDFS > Issue Type: New Feature >Affects Versions: 3.4.0 >Reporter: liusheng >Assignee: zZtai >Priority: Major > Labels: sm4 > Attachments: HDFS-15098.001.patch, HDFS-15098.002.patch, > HDFS-15098.003.patch, HDFS-15098.004.patch, HDFS-15098.005.patch, > HDFS-15098.006.patch, HDFS-15098.007.patch, HDFS-15098.008.patch > > > SM4 (formerly SMS4)is a block cipher used in the Chinese National Standard > for Wireless LAN WAPI (Wired Authentication and Privacy Infrastructure). > SM4 was a cipher proposed to for the IEEE 802.11i standard, but has so far > been rejected by ISO. One of the reasons for the rejection has been > opposition to the WAPI fast-track proposal by the IEEE. please see: > [https://en.wikipedia.org/wiki/SM4_(cipher)] > > *Use sm4 on hdfs as follows:* > 1.download Bouncy Castle Crypto APIs from bouncycastle.org > [https://bouncycastle.org/download/bcprov-ext-jdk15on-165.jar] > 2.Configure JDK > Place bcprov-ext-jdk15on-165.jar in $JAVA_HOME/jre/lib/ext directory, > add "security.provider.10=org.bouncycastle.jce.provider.BouncyCastleProvider" > to $JAVA_HOME/jre/lib/security/java.security file > 3.Configure Hadoop KMS > 4.test HDFS sm4 > hadoop key create key1 -cipher 'SM4/CTR/NoPadding' > hdfs dfs -mkdir /benchmarks > hdfs crypto -createZone -keyName key1 -path /benchmarks > *requires:* > 1.openssl version >=1.1.1 > 2.configure Bouncy Castle Crypto on JDK -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Updated] (HDFS-15098) Add SM4 encryption method for HDFS
[ https://issues.apache.org/jira/browse/HDFS-15098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zZtai updated HDFS-15098: - Attachment: (was: HDFS-15098.008.patch) > Add SM4 encryption method for HDFS > -- > > Key: HDFS-15098 > URL: https://issues.apache.org/jira/browse/HDFS-15098 > Project: Hadoop HDFS > Issue Type: New Feature >Affects Versions: 3.4.0 >Reporter: liusheng >Assignee: zZtai >Priority: Major > Labels: sm4 > Attachments: HDFS-15098.001.patch, HDFS-15098.002.patch, > HDFS-15098.003.patch, HDFS-15098.004.patch, HDFS-15098.005.patch, > HDFS-15098.006.patch, HDFS-15098.007.patch > > > SM4 (formerly SMS4)is a block cipher used in the Chinese National Standard > for Wireless LAN WAPI (Wired Authentication and Privacy Infrastructure). > SM4 was a cipher proposed to for the IEEE 802.11i standard, but has so far > been rejected by ISO. One of the reasons for the rejection has been > opposition to the WAPI fast-track proposal by the IEEE. please see: > [https://en.wikipedia.org/wiki/SM4_(cipher)] > > *Use sm4 on hdfs as follows:* > 1.download Bouncy Castle Crypto APIs from bouncycastle.org > [https://bouncycastle.org/download/bcprov-ext-jdk15on-165.jar] > 2.Configure JDK > Place bcprov-ext-jdk15on-165.jar in $JAVA_HOME/jre/lib/ext directory, > add "security.provider.10=org.bouncycastle.jce.provider.BouncyCastleProvider" > to $JAVA_HOME/jre/lib/security/java.security file > 3.Configure Hadoop KMS > 4.test HDFS sm4 > hadoop key create key1 -cipher 'SM4/CTR/NoPadding' > hdfs dfs -mkdir /benchmarks > hdfs crypto -createZone -keyName key1 -path /benchmarks > *requires:* > 1.openssl version >=1.1.1 > 2.configure Bouncy Castle Crypto on JDK -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Updated] (HDFS-15098) Add SM4 encryption method for HDFS
[ https://issues.apache.org/jira/browse/HDFS-15098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zZtai updated HDFS-15098: - Status: Open (was: Patch Available) > Add SM4 encryption method for HDFS > -- > > Key: HDFS-15098 > URL: https://issues.apache.org/jira/browse/HDFS-15098 > Project: Hadoop HDFS > Issue Type: New Feature >Affects Versions: 3.4.0 >Reporter: liusheng >Assignee: zZtai >Priority: Major > Labels: sm4 > Attachments: HDFS-15098.001.patch, HDFS-15098.002.patch, > HDFS-15098.003.patch, HDFS-15098.004.patch, HDFS-15098.005.patch, > HDFS-15098.006.patch, HDFS-15098.007.patch, HDFS-15098.008.patch > > > SM4 (formerly SMS4)is a block cipher used in the Chinese National Standard > for Wireless LAN WAPI (Wired Authentication and Privacy Infrastructure). > SM4 was a cipher proposed to for the IEEE 802.11i standard, but has so far > been rejected by ISO. One of the reasons for the rejection has been > opposition to the WAPI fast-track proposal by the IEEE. please see: > [https://en.wikipedia.org/wiki/SM4_(cipher)] > > *Use sm4 on hdfs as follows:* > 1.download Bouncy Castle Crypto APIs from bouncycastle.org > [https://bouncycastle.org/download/bcprov-ext-jdk15on-165.jar] > 2.Configure JDK > Place bcprov-ext-jdk15on-165.jar in $JAVA_HOME/jre/lib/ext directory, > add "security.provider.10=org.bouncycastle.jce.provider.BouncyCastleProvider" > to $JAVA_HOME/jre/lib/security/java.security file > 3.Configure Hadoop KMS > 4.test HDFS sm4 > hadoop key create key1 -cipher 'SM4/CTR/NoPadding' > hdfs dfs -mkdir /benchmarks > hdfs crypto -createZone -keyName key1 -path /benchmarks > *requires:* > 1.openssl version >=1.1.1 > 2.configure Bouncy Castle Crypto on JDK -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (HDFS-15430) create should work when parent dir is internalDir and fallback configured.
[ https://issues.apache.org/jira/browse/HDFS-15430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17151202#comment-17151202 ] Uma Maheswara Rao G edited comment on HDFS-15430 at 7/5/20, 10:35 PM: -- Thanks [~weichiu] and [~ayushtkn] for reviews!!! I have just committed this to trunk. was (Author: umamaheswararao): Thanks [~ayushtkn] for reviews!!! I have just committed this to trunk. > create should work when parent dir is internalDir and fallback configured. > --- > > Key: HDFS-15430 > URL: https://issues.apache.org/jira/browse/HDFS-15430 > Project: Hadoop HDFS > Issue Type: Sub-task >Affects Versions: 3.2.1 >Reporter: Uma Maheswara Rao G >Assignee: Uma Maheswara Rao G >Priority: Major > Fix For: 3.4.0 > > > create will not work if the parent dir is Internal mount dir (non leaf in > mount path) and fall back configured. > Since fallback is available and if same tree structure available in fallback, > we should be able to create in fallback fs. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Updated] (HDFS-15438) Setting dfs.disk.balancer.max.disk.errors = 0 will fail the block copy
[ https://issues.apache.org/jira/browse/HDFS-15438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AMC-team updated HDFS-15438: Attachment: HDFS-15438.000.patch > Setting dfs.disk.balancer.max.disk.errors = 0 will fail the block copy > -- > > Key: HDFS-15438 > URL: https://issues.apache.org/jira/browse/HDFS-15438 > Project: Hadoop HDFS > Issue Type: Bug > Components: balancer & mover >Reporter: AMC-team >Priority: Major > Attachments: HDFS-15438.000.patch > > > In HDFS disk balancer, the config parameter > "dfs.disk.balancer.max.disk.errors" is to control the value of maximum number > of errors we can ignore for a specific move between two disks before it is > abandoned. > The parameter can accept value that >= 0. And setting the value to 0 should > mean no error tolerance. However, setting the value to 0 will simply don't do > the block copy even there is no disk error occur because the while loop > condition *item.getErrorCount() < getMaxError(item)* will not satisfied. > {code:java} > // Gets the next block that we can copy > private ExtendedBlock getBlockToCopy(FsVolumeSpi.BlockIterator iter, > DiskBalancerWorkItem item) { > while (!iter.atEnd() && item.getErrorCount() < getMaxError(item)) { > try { > ... //get the block > } catch (IOException e) { > item.incErrorCount(); > } >if (item.getErrorCount() >= getMaxError(item)) { > item.setErrMsg("Error count exceeded."); > LOG.info("Maximum error count exceeded. Error count: {} Max error:{} > ", > item.getErrorCount(), item.getMaxDiskErrors()); > } > {code} > *How to fix* > Change the while loop condition to support value 0. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Updated] (HDFS-15438) Setting dfs.disk.balancer.max.disk.errors = 0 will fail the block copy
[ https://issues.apache.org/jira/browse/HDFS-15438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AMC-team updated HDFS-15438: Attachment: (was: HDFS-15438.000.patch) > Setting dfs.disk.balancer.max.disk.errors = 0 will fail the block copy > -- > > Key: HDFS-15438 > URL: https://issues.apache.org/jira/browse/HDFS-15438 > Project: Hadoop HDFS > Issue Type: Bug > Components: balancer & mover >Reporter: AMC-team >Priority: Major > > In HDFS disk balancer, the config parameter > "dfs.disk.balancer.max.disk.errors" is to control the value of maximum number > of errors we can ignore for a specific move between two disks before it is > abandoned. > The parameter can accept value that >= 0. And setting the value to 0 should > mean no error tolerance. However, setting the value to 0 will simply don't do > the block copy even there is no disk error occur because the while loop > condition *item.getErrorCount() < getMaxError(item)* will not satisfied. > {code:java} > // Gets the next block that we can copy > private ExtendedBlock getBlockToCopy(FsVolumeSpi.BlockIterator iter, > DiskBalancerWorkItem item) { > while (!iter.atEnd() && item.getErrorCount() < getMaxError(item)) { > try { > ... //get the block > } catch (IOException e) { > item.incErrorCount(); > } >if (item.getErrorCount() >= getMaxError(item)) { > item.setErrMsg("Error count exceeded."); > LOG.info("Maximum error count exceeded. Error count: {} Max error:{} > ", > item.getErrorCount(), item.getMaxDiskErrors()); > } > {code} > *How to fix* > Change the while loop condition to support value 0. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Updated] (HDFS-15438) Setting dfs.disk.balancer.max.disk.errors = 0 will fail the block copy
[ https://issues.apache.org/jira/browse/HDFS-15438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AMC-team updated HDFS-15438: Attachment: (was: HDFS-15438.000.patch) > Setting dfs.disk.balancer.max.disk.errors = 0 will fail the block copy > -- > > Key: HDFS-15438 > URL: https://issues.apache.org/jira/browse/HDFS-15438 > Project: Hadoop HDFS > Issue Type: Bug > Components: balancer & mover >Reporter: AMC-team >Priority: Major > Attachments: HDFS-15438.000.patch > > > In HDFS disk balancer, the config parameter > "dfs.disk.balancer.max.disk.errors" is to control the value of maximum number > of errors we can ignore for a specific move between two disks before it is > abandoned. > The parameter can accept value that >= 0. And setting the value to 0 should > mean no error tolerance. However, setting the value to 0 will simply don't do > the block copy even there is no disk error occur because the while loop > condition *item.getErrorCount() < getMaxError(item)* will not satisfied. > {code:java} > // Gets the next block that we can copy > private ExtendedBlock getBlockToCopy(FsVolumeSpi.BlockIterator iter, > DiskBalancerWorkItem item) { > while (!iter.atEnd() && item.getErrorCount() < getMaxError(item)) { > try { > ... //get the block > } catch (IOException e) { > item.incErrorCount(); > } >if (item.getErrorCount() >= getMaxError(item)) { > item.setErrMsg("Error count exceeded."); > LOG.info("Maximum error count exceeded. Error count: {} Max error:{} > ", > item.getErrorCount(), item.getMaxDiskErrors()); > } > {code} > *How to fix* > Change the while loop condition to support value 0. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Updated] (HDFS-15438) Setting dfs.disk.balancer.max.disk.errors = 0 will fail the block copy
[ https://issues.apache.org/jira/browse/HDFS-15438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AMC-team updated HDFS-15438: Attachment: HDFS-15438.000.patch > Setting dfs.disk.balancer.max.disk.errors = 0 will fail the block copy > -- > > Key: HDFS-15438 > URL: https://issues.apache.org/jira/browse/HDFS-15438 > Project: Hadoop HDFS > Issue Type: Bug > Components: balancer & mover >Reporter: AMC-team >Priority: Major > Attachments: HDFS-15438.000.patch > > > In HDFS disk balancer, the config parameter > "dfs.disk.balancer.max.disk.errors" is to control the value of maximum number > of errors we can ignore for a specific move between two disks before it is > abandoned. > The parameter can accept value that >= 0. And setting the value to 0 should > mean no error tolerance. However, setting the value to 0 will simply don't do > the block copy even there is no disk error occur because the while loop > condition *item.getErrorCount() < getMaxError(item)* will not satisfied. > {code:java} > // Gets the next block that we can copy > private ExtendedBlock getBlockToCopy(FsVolumeSpi.BlockIterator iter, > DiskBalancerWorkItem item) { > while (!iter.atEnd() && item.getErrorCount() < getMaxError(item)) { > try { > ... //get the block > } catch (IOException e) { > item.incErrorCount(); > } >if (item.getErrorCount() >= getMaxError(item)) { > item.setErrMsg("Error count exceeded."); > LOG.info("Maximum error count exceeded. Error count: {} Max error:{} > ", > item.getErrorCount(), item.getMaxDiskErrors()); > } > {code} > *How to fix* > Change the while loop condition to support value 0. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-15312) Apply umask when creating directory by WebHDFS
[ https://issues.apache.org/jira/browse/HDFS-15312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17151519#comment-17151519 ] Ye Ni commented on HDFS-15312: -- [~inigoiri] Done. > Apply umask when creating directory by WebHDFS > -- > > Key: HDFS-15312 > URL: https://issues.apache.org/jira/browse/HDFS-15312 > Project: Hadoop HDFS > Issue Type: Improvement > Components: webhdfs >Reporter: Ye Ni >Assignee: Ye Ni >Priority: Minor > > WebHDFS methods for creating file/directories were always creating it with > 755 permissions as default for both files and directories. > The configured *fs.permissions.umask-mode* is intentionally ignored. > This Jira is to apply this setting in such scenario. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org