bobpaulin commented on code in PR #11872:
URL: https://github.com/apache/nifi/pull/11872#discussion_r4484658623
##########
nifi-framework-bundle/nifi-framework/nifi-framework-cluster/src/main/java/org/apache/nifi/cluster/manager/ConnectorEntityMerger.java:
##########
@@ -202,6 +238,45 @@ private static void mergeState(final ConnectorDTO
clientDto, final Map<NodeIdent
clientDto.setState(mergedState);
}
+ private static void mergeFlowEvolutionStatus(final ConnectorDTO clientDto,
final Map<NodeIdentifier, ConnectorDTO> dtoMap) {
+ boolean anyPhaseTwo = false;
+ boolean anyEarlierPhase = false;
+ for (final ConnectorDTO nodeConnector : dtoMap.values()) {
+ final FlowEvolutionStatus status =
reportedFlowEvolutionStatus(nodeConnector);
+ if (status == FlowEvolutionStatus.PHASE_TWO_COMPLETE) {
+ anyPhaseTwo = true;
+ } else if (status == FlowEvolutionStatus.PHASE_ONE_PENDING ||
status == FlowEvolutionStatus.PHASE_ONE_COMPLETE) {
+ anyEarlierPhase = true;
+ }
+ }
+ // A node that has finished reports INACTIVE once it is RUNNING. While
a peer is still at phase two, count the
+ // finished node as phase two. Doing that for an earlier phase would
hide a node that has not started.
+ final boolean countRunningInactiveAsPhaseTwo = anyPhaseTwo &&
!anyEarlierPhase;
Review Comment:
I had not considered using PREPARING_FOR_UPDATE, then UPDATING likely
because there were more barriers than existing states. For example assume
PREPARING_FOR_UPDATE = PHASE_ONE_PENDING then UPDATING would have to represent
both PHASE_ONE_COMPLETE and PHASE_TWO_COMPLETE. I need to ensure the cluster
is drained and ready for Phase 2 as this is where the persisted flow is
replaced with the new active flow. I also needed to be able to roll back to
different places if the drain failed vs the new flow creation failed. While I
can see why this simplification is attractive I'm not convinced that we can
reliably prevent the cluster from getting to a bad state without introducing
more connector states to map to the FlowEvolutionStatus. I was trying not to
add additional ConnectorState to manage.
Open to discussing more on expanding ConnectorState vs adding
FlowEvolutionStatus but I think we're not in a spot where we can simply reused
existing ConnectorState as is.
--
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]
