[ https://issues.apache.org/jira/browse/HDDS-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903443#comment-16903443 ]
Arpit Agarwal edited comment on HDDS-1554 at 8/9/19 4:18 AM: ------------------------------------------------------------- A few comments on the test case implementations. # {{ITDiskReadOnly#testReadOnlyDiskStartup}} - The following block of code can probably be removed, since it's really testing that the cluster is read-only in safe mode. We have unit tests for that: {code:java} try { createVolumeAndBucket(); } catch (Exception e) { LOG.info("Bucket creation failed for read-only disk: ", e); Assert.assertTrue("Cluster is still in safe mode.", safeMode); } {code} # {{ITDiskReadOnly#testUpload}} - do we need to wait for safe mode exit after restarting the cluster? Also I think this test is essentially the same as the previous one. # {{ITDiskCorruption#addCorruption:72}} - looks like we have a hard-coded path. Should we get from configuration instead? # {{ITDiskCorruption#testUpload}} - The corruption implementation is bit of a heavy hammer, it is replacing the content of all meta files. Is it possible to make it reflect real-world corruption where a part of the file may be corrupted. Also we should probably restart the cluster after corrupting RocksDB meta files. # {{ITDiskCorruption#testDownload:161}} - should we just remove the assertTrue since it is no-op? {code:java} Assert.assertTrue("Download File test passed.", true); {code} was (Author: arpitagarwal): A few comments on the test case implementations. # {{ITDiskReadOnly#testReadOnlyDiskStartup}} - The following block of code can probably be removed, since it's really testing that the cluster is read-only in safe mode. We have unit tests for that: {code} try { createVolumeAndBucket(); } catch (Exception e) { LOG.info("Bucket creation failed for read-only disk: ", e); Assert.assertTrue("Cluster is still in safe mode.", safeMode); } {code} # {{ITDiskReadOnly#testUpload}} - do we need to wait for safe mode exit after restarting the cluster? Also I think this test is essentially the same as the previous one. # {{ITDiskCorruption#addCorruption:72}} - looks like we have a hard-coded path. Should we get from configuration instead? # {{ITDiskCorruption#testUpload}} - The corruption implementation is bit of a heavy hammer, it is replacing the content of all meta files. Is it possible to make it reflect real-world corruption where a part of the file may be corrupted. Also we should probably restart the cluster after corrupting RocksDB meta files. # {{ITDiskCorruption#testDownload:161}} - should we just remove the assertTrue since it is no-op? {code} Assert.assertTrue("Download File test passed.", true); {code} Still reviewing the rest. > Create disk tests for fault injection test > ------------------------------------------ > > Key: HDDS-1554 > URL: https://issues.apache.org/jira/browse/HDDS-1554 > Project: Hadoop Distributed Data Store > Issue Type: Improvement > Components: build > Reporter: Eric Yang > Assignee: Eric Yang > Priority: Major > Labels: pull-request-available > Attachments: HDDS-1554.001.patch, HDDS-1554.002.patch, > HDDS-1554.003.patch, HDDS-1554.004.patch, HDDS-1554.005.patch, > HDDS-1554.006.patch, HDDS-1554.007.patch, HDDS-1554.008.patch, > HDDS-1554.009.patch, HDDS-1554.010.patch, HDDS-1554.011.patch, > HDDS-1554.012.patch, HDDS-1554.013.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > > The current plan for fault injection disk tests are: > # Scenario 1 - Read/Write test > ## Run docker-compose to bring up a cluster > ## Initialize scm and om > ## Upload data to Ozone cluster > ## Verify data is correct > ## Shutdown cluster > # Scenario 2 - Read/Only test > ## Repeat Scenario 1 > ## Mount data disk as read only > ## Try to write data to Ozone cluster > ## Validate error message is correct > ## Shutdown cluster > # Scenario 3 - Corruption test > ## Repeat Scenario 2 > ## Shutdown cluster > ## Modify data disk data > ## Restart cluster > ## Validate error message for read from corrupted data > ## Validate error message for write to corrupted volume -- This message was sent by Atlassian JIRA (v7.6.14#76016) --------------------------------------------------------------------- To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org