[
https://issues.apache.org/jira/browse/ZOOKEEPER-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14145782#comment-14145782
]
some one commented on ZOOKEEPER-2031:
-------------------------------------
My last comment was wrong, sorry. I was observing the reconfig add failure only
because I was using only the QuorumServer string instead of "server.id=" +
QS.toString().
So I do see that we are able to add the overlapping server with a different
tag, which ends up overwriting the existing server.
On one hand, this is symmetric with the behavior that I was originally
intending, which was that in the remove scenario, the user should guard against
removing the wrong server.
The same could be said for the addition of a server, where the user should make
sure they are specifying the version when they are adding a server, to
explicitly indicate that they know they are overwriting the existing server.
However on the other hand, since I've already added code in FLE to prevent an
overlapping QuorumServer from syncing to the wrong cluster, I could see the
argument for making sure everything else understands the tag as well. But the
difference is that the syncing happens automatically in the background when an
overlapping QuorumServer is brought up, whereas the user adding/removing nodes
is explicit.
Personally I'd say that we leave it up to the user to guard against this
situation for now, since I don't believe it differs from the existing behavior
much. But they do get the benefit of now being able to somewhat coordinate
concurrent joins/kicks of overlapping servers.
> Support tagging a QuorumServer
> ------------------------------
>
> Key: ZOOKEEPER-2031
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2031
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
> Reporter: some one
> Assignee: some one
> Fix For: 3.5.1, 3.6.0
>
> Attachments: ZOOKEEPER-2031-Additional.patch, ZOOKEEPER-2031.patch
>
>
> Currently ZooKeeper only allows using the server id which is an integer for
> identifying servers. For my (unavoidable) use case, there may be concurrent
> dynamic removes and adds of servers which may eventually have id collisions.
> When this occurs, there is no good way to determine if the server (given an
> id collision) that we want to remove is the right server.
> To support my use case, I propose that we add a tag field to the server
> string.
> For my specific use case, this tag field will be used to store a uuid as a
> string.
> So for example:
> server.1=127.0.0.1:1234:1236:participant;0.0.0.0:1237;743b9d23-85cb-45b1-8949-930fdabb21f0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
