It does both, it first proposes by writing a sequential znode and then reads the children (all proposals are written under some parent znode). This is certainly assuming some experience with ZK, and I wonder if that's the problem. It was not the goal to go into a discussion of the ZooKeeper API, but I'm happy to clarify if this is what is preventing you from getting the point.
>> Not suppose to ? How do you ensure that ?
It is not supposed to in the sense that if this is implemented right, then the proposed values for each client won't change. The recipe guarantees it because it assumes that each client writes just once.
>> Sorry, but I fail to see what recipe you speak about.
I'm referring to these three steps: creating a sequential znode under a known parent, reading the children, picking the value in the znode with smallest sequence number.
What I find vague in "ZooKeeper and consensus" is the answer to "Why does this proposal work compared to the original one?":
>> Because each of the workers has “proposed” a single value
Does the processes read or propose the value ?
>> and no changes to those values are supposed to occur.
Not suppose to ? How do you ensure that ?
>> Over time, as the configurator changes the value,
>> they can agree on the different values by running independent instances
>> of this simple agreement recipe.
Sorry, but I fail to see what recipe you speak about.