Well, from my point of view it at least makes sense to abstract out the implementation. Now any attempt to replace ZK with something else will lead to significant efforts. So, even providing of pluggable interface for the consensus and metadata would be extremely helpful and would enable other people to provide replacement for ZK-based implementation. There are many situations when ZK is too inconvenient. For example, ZK is very inconvenient for embedding. This in turn makes embedding of Kafka very inconvenient too (while Kafka itself is quite convenient in this regard).
Also, jgroups-raft is only one implementation of RAFT. There are several others which potentially can be used for this purpose. 2015-08-17 16:42 GMT+03:00 Joe Stein <joe.st...@stealth.ly>: > I don't think it makes sense to change the core default implementation with > KIP-30. Too much risk both in stability and in increasing the time to > getting it done and available for folks that want to try Kafka without > Zookeeper. > > It would be interesting to see how that implementation would work along > with the others too if that would be something folks wanted to support in > their environment I encourage that. > > I will be sending out a discuss thread on KIP-30 hopefully in the next day > or so we can go back and forth on the motivations and purposes behind it > and whatever technical details are required too of course. > > ~ Joe Stein > > On Mon, Aug 17, 2015 at 9:29 AM, Sergiy Yevtushenko < > sergiy.yevtushe...@gmail.com> wrote: > > > Hi, > > > > Are there any plans to work on this improvement? > > As a possible core for default implementation it might worth to consider > > https://github.com/belaban/jgroups-raft . > > It already contains RAFT consensus algorithm implementation. Adding > > something like distributed hash map for shared metadata should not be an > > issue. > > > > Regards, > > Sergiy. > > >
