Hi Flavio, I've been basically working on my own branch for many months now. The problem is that the main trunk is changing all the time, and of course the merge is difficult as you mentioned. Although my implementation is pretty stable, testing on my own branch doesn't mean that it will work in the trunk.
At this point, Ben and I decided to do the merge by partitioning the work into multiple patches, each of which will be well-defined, tested separately and easier to review. So far I have 1 such patch ready - this is Zookeeper-1355 which is waiting to be reviewed. Currently I'm working on 3 more patches, which I'd like to get in before the main algorithm: 1. Separating membership information from the main configuration file. This will not only be needed for reconfiguration but also makes it easier to configure the current system - this way you can have a single membership file and all servers can have a copy. 2. Changing the way the list of peers is stored in QuorumPeer. This eliminates quorumPeers and instead stores the list in a QuorumVerifier. The QuorumVerifier basically becomes a representation of a configuration - it knows who are the voters, who are the observers, etc. This will also solve the current zookeeper bug that allows any connected follower to vote (last week a related bug was solved where observers were counted in the code of the leader, however the same problem appears in many other places in the code, such as leader election and other places in leader code). 3. Each proposal has a set of configurations (QuorumVerifiers) from which it needs an ack in order to commit. Currently each proposal has just one associated configuration. Testing and merging these patches first will make it much much easier to add the reconfiguration algorithm and to test it. Alex > -----Original Message----- > From: Flavio Junqueira [mailto:f...@yahoo-inc.com] > Sent: Friday, January 20, 2012 9:25 AM > To: dev@zookeeper.apache.org > Subject: Branch for reconfiguration (ZOOKEEPER-107)? > > This message is to throw the idea and get a sense of what people > think, especially the ones working closely on it like Alex, about > creating a branch for the reconfiguration work. The rationale for > proposing it is the following. In our experience with Zab last year, > we implemented modifications that introduced a bunch of critical bugs. > I'm not sure whether we could have been more careful, maybe so, but my > perception is that it is not unusual to introduce such bugs once one > touches upon a large chunk of core code. Perhaps it would have been > better to develop it on the side and test more before merging. > > For reconfiguration, it sounds like we will be touching a big chunk of > core code again, so I wonder if it makes sense to work on a separate > branch, test, and merge once we are convinced. I must also say that I > understand that merging branches can be quite a pain, so I would > completely understand if the general feeling is that it outweighs the > benefits. > > Thanks, > -Flavio
