A quote from the Jira ticket where Sebastian tries to explain their setup: (see https://issues.apache.org/jira/browse/ZOOKEEPER-2164?focusedCommentId=17037941&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17037941 )
"We are using 0.0.0.0 in our config of the 3-node-cluster as the nodes are running in separate docker-instances not directly connected to each other. Which means the zookeeper-container doesn't have its real IP assigned only using port-forwardings from the docker host to the container to make it accessible and so using the external IP or the FQDN doesn't allow zookeeper to start as it complains about not finding that IP in the container. Which is of course correct. Using the internal Network-IP instead of 0.0.0.0 would result in the same problem as using 0.0.0.0 as all internal networks of the three docker hosts are using the same network-range in their internal networks." re-reading it, I think he meant a bit different config than what I wrote as an example before... I think he basically connects separate hosts with tunnels maybe and running ZK in docker in each host without any container orchestration tool. (?) On Tue, Feb 18, 2020 at 10:49 AM Enrico Olivelli <[email protected]> wrote: > Honestly I think that using 0.0.0.0 is not so useful. > I find it very useful that the configuration is the same on every peer, > except from myid file > What's the real gain in such configuration? > > > Enrico > > > Il Mar 18 Feb 2020, 10:32 Szalay-Bekő Máté <[email protected]> ha > scritto: > > > Hi All, > > > > in a recent PR I try to fix an issue we found with Suhas Dantkale in > > ZOOKEEPER-2146 (see https://github.com/apache/zookeeper/pull/1254). The > > problem is that in ZooKeeper 3.5+ some quorum members can not rejoin to > the > > quorum after a restart if the server configs are set like this: > > > > zoo.cfg in server 1: > > server.1=0.0.0.0:2888:3888 > > server.2=some.fqdn-2.com:2888:3888 > > server.3=some.fqdn-3.com:2888:3888 > > > > zoo.cfg in server 2: > > server.1=some.fqdn-1.com:2888:3888 > > server.2=0.0.0.0:2888:3888 > > server.3=some.fqdn-3.com:2888:3888 > > > > I am not exactly sure about the use case behind this config, but people > > claim they need it for specific dockerized environments (see the comments > > in the jira ticket). Is anyone familiar with such use cases? We never > used > > such configs in production as far as I can tell. > > > > The above config worked without a problem in ZooKeeper 3.4.x, but not > > perfectly for 3.5.x. It would be logical to keep supporting it. Still, I > > think after the introduction of the dynamic reconfig, we kind of assume > > that all the servers have the same server address configurations. So > maybe > > the config is not even valid anymore? > > > > Using the 'quorumListenOnAllIPs' config property instead the 0.0.0.0 in > the > > configs might solve the issue. But if it is the case, then we definitely > > should highlight this in the wiki / documentation. Maybe even printing > out > > a warning during ZooKeeper startup. > > > > What do you think? > > > > Kind regards, > > Mate > > >
