markap14 commented on PR #6560: URL: https://github.com/apache/nifi/pull/6560#issuecomment-1287325601
@michael81877 nope you're correct, that this change does not affect the startup for a standalone node. I was merely pointing out that having different logic for standalone and for clustered nodes is very much intentional, not an oversight. The `USE_SPECIFIED_OR_COMPATIBLE_OR_GHOST` strategy is used on startup for standalone nodes. This allows us to automatically upgrade processors from 1.18 to 1.19 when you upgrade, or to startup with a ghosted component if it's not available. But we don't want that behavior when connecting to a cluster. We don't want some nodes ghosting a component while others do not. You do have a good point on the protocol version negotiation for site-to-site and load balancing. But we don't have the same for the cluster protocol, which would be important. The scenario where one node could be missing or has an outdated version of an extension is not necessarily an operator error. This will always be the case when doing a rolling upgrade. Some nodes will be on one version of an extension (say 1.19) while others will be on another version of the extension (say 1.20). The new version may have additional properties, or may be missing certain properties. Or Relationships. But even after the upgrade, there could be a mismatch of versions. And yes, that would likely imply operator error. But just because something is operator error doesn't mean that we should simply let it happen and blame the operator. To the extent that's reasonable, we should prevent operators from doing things that we know are wrong. To be clear here, I'm not saying "No way, let's not allow for rolling upgrades!" What I am saying is: "The current value is there intentionally, it's not a bug. We don't want to just switch it and assume that no problems will arise. If we want to go down the path of allowing rolling upgrades, we need to do so carefully and think through all of the consequences and make sure that the changes that we're making make sense." -- 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]
