While I'm not in favor of the proposal, I want to point out that the ecosystem changed quite a bit since KIP-30 was first proposed. Kubernetes deployments are far more common now and are growing in popularity, and the problem in deployment, discovery and management that ZK poses is therefore more relevant now than it was at the time. There are reasons for the community to change its collective mind even if the objections are still valid.
Since the KIP doesn't include the etcd implementation, the proposal looks like very simple refactoring. Of course, the big change is a new public API. But it's difficult to judge from the KIP if the API is a good one because it is built to 100% match the one implementation we have. I'm curious if the plan includes contributing the Etcd module to Apache Kafka? On Wed, Mar 28, 2018 at 9:54 AM, Ismael Juma <ism...@juma.me.uk> wrote: > Thanks for the KIP. This was proposed previously via "KIP-30 Allow for > brokers to have plug-able consensus and meta data storage sub systems" and > the community was not in favour. Have you considered the points discussed > then? > > Ismael > > On Wed, Mar 28, 2018 at 9:18 AM, Molnár Bálint <molnarcsi...@gmail.com> > wrote: > > > Hi all, > > > > I have created KIP-273: Kafka to support using ETCD beside Zookeeper > > > > Here is the link to the KIP: > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP- > > 273+-+Kafka+to+support+using+ETCD+beside+Zookeeper > > > > Looking forward to the discussion. > > > > Thanks, > > Balint > > > -- *Gwen Shapira* Product Manager | Confluent 650.450.2760 | @gwenshap Follow us: Twitter <https://twitter.com/ConfluentInc> | blog <http://www.confluent.io/blog>