errose28 commented on code in PR #7976:
URL: https://github.com/apache/ozone/pull/7976#discussion_r1977979764
##########
hadoop-hdds/server-scm/src/test/java/org/apache/hadoop/hdds/scm/container/TestContainerReportHandler.java:
##########
@@ -446,64 +484,70 @@ public void testClosingToClosedForECContainer()
}
/**
- * Tests that a DELETING RATIS container transitions to CLOSED if a
non-empty CLOSED replica is reported. It does not
- * transition if a non-empty CLOSING replica is reported.
+ * Tests that a DELETING or DELETED RATIS container transitions to CLOSED if
a non-empty replica in OPEN, CLOSING,
+ * CLOSED, QUASI_CLOSED or UNHEALTHY state is reported. It should not
transition if the replica is in INVALID or
+ * DELETED states.
*/
- @Test
- public void
ratisContainerShouldTransitionFromDeletingToClosedWhenNonEmptyClosedReplica()
throws IOException {
- ContainerInfo container = getContainer(LifeCycleState.DELETING);
+ @ParameterizedTest
+ @MethodSource("containerAndReplicaStates")
+ public void
ratisContainerShouldTransitionFromDeletingOrDeletedToClosedWhenNonEmptyReplica(
Review Comment:
The handling should be same regardless of replication type. Right now there
is more coverage for the Ratis case but we need Ratis and EC to have the same
coverage. Can you elaborate on what the difference is? We need to make sure it
is not exposing a legitimate issue.
##########
hadoop-hdds/server-scm/src/main/java/org/apache/hadoop/hdds/scm/container/ContainerReportHandler.java:
##########
@@ -234,7 +234,7 @@ private void processSingleReplica(final DatanodeDetails
datanodeDetails,
UNKNOWN_CONTAINER_ACTION_DELETE)) {
final ContainerID containerId = ContainerID
.valueOf(replicaProto.getContainerID());
- deleteReplica(containerId, datanodeDetails, publisher, "unknown");
+ deleteReplica(containerId, datanodeDetails, publisher, "unknown",
false);
Review Comment:
Not sure whether we should use force delete here or not. It is already
behind a config key that defaults to off and is not really needed or used for
any situations currently. I would imagine the config would only be turned on if
there was a non-empty container that needed to be removed for some reason
anyways, hence force might make sense. I'm ok with either option though.
##########
hadoop-hdds/server-scm/src/main/java/org/apache/hadoop/hdds/scm/container/AbstractContainerReportHandler.java:
##########
@@ -357,21 +357,21 @@ private boolean updateContainerState(final
DatanodeDetails datanode,
* HDDS-11136: If a DELETING container has a non-empty CLOSED replica,
the container should be moved back to
* CLOSED state.
*
- * HDDS-12421: If a DELETED container has a non-empty CLOSED replica,
the container should also be moved back to
- * CLOSED state.
+ * HDDS-12421: If a DELETING or DELETED container has a non-empty
replica, the container should also be moved
+ * back to CLOSED state.
*/
-
boolean replicaIsEmpty = replica.hasIsEmpty() && replica.getIsEmpty();
// If container is in DELETED state and the reported replica is empty,
delete the empty replica.
+ // We should also do this for DELETING containers and currently
DeletingContainerHandler does that
if (container.getState() == HddsProtos.LifeCycleState.DELETED &&
replicaIsEmpty) {
+ // should we send a non-force delete instead?
deleteReplica(containerId, datanode, publisher, "DELETED");
ignored = true;
break;
}
- boolean replicaStateAllowed = replica.getState() == State.CLOSED;
- boolean replicaNotEmpty = replica.hasIsEmpty() && !replica.getIsEmpty();
Review Comment:
Looks to me like it is ok to omit the existence check for the field, but
Siddhant should confirm.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
