showuon commented on PR #20859: URL: https://github.com/apache/kafka/pull/20859#issuecomment-3587892645
> Why make the proposed semantic idempotent per (ReplicaKey + process incarnation) tuple? I would argue that having the node try to auto-join on restart is just as confusing UX. In the original use case, if the node just gets restarted, we end up in the same place of the controller rejoining the voter set when we don't "want" it to (i.e. after an explicit removal). Yes, I know what you mean. I don't have a good answer on this TBH. I just know it's better than "auto-joining a just removed voter". > Another approach is we can make auto-join idempotent per ReplicaKey and handle this server-side. I think this approach best captures the intent of the feature and maintains a good UX. Basically, when I startup a new observer controller with auto-join, it will join the quorum automatically at most once for the lifetime of its ReplicaKey. After an explicit removal, the leader can return a special error for a subsequent auto-join request from the same ReplicaKey to tell the node to stop sending AddVoter. If the controller's disk fails and it restarts, it will have a new ReplicaKey, and will auto-join again (this is the intended behavior because it is essentially a completely new controller). This does not require a KIP, and would be simpler to implement than either of the discussed approaches. 1. `make auto-join idempotent per ReplicaKey ` -> +1 2. `it will join the quorum automatically at most once for the lifetime of its ReplicaKey` -> I don't know how we define the `automatically join`. Does it count for the initial controllers or not? Does it count for `manually join`? -- 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]
