I think that this is a good direction to go.

I believe to the reasons about ZK in huge systems even it is not my case so
I cannot add comments on this usecase.

I am fine with direction as long as we are still going to support ZooKeeper.
BookKeeper is in the Hadoop / ZooKeeper ecosystem and several products rely
on ZK too, for instance in my systems it is usual to have
BookKeeper/Kafka/HBase/Majordodo....  and so I am not going to live without
zookeeper in the short/mid term.

I am really OK in dropping ZK because for "simple" systems in fact when you
need only BK having the burden of setting up a zookeeper server is weird
for customers. I usually re-distribute BK + ZK with my applications and we
are talking about little clusters of up to 10 machines.

The direction on this proposal is OK for me and it is very like the work I
was starting about "standalone mode".

I think it will be very easy to support the case of having a single bookie
with this approach or even client+ bookie in the same JVM,
Having multiple bookies will make us to add some other coordination
facility between bookies, I would like to know if there is already some
idea about this, are we going to use another product like etcd,jgroups or
implement our own coordination protocol ? ZK is simple but it very
effective. Maybe we could help the ZK community to move forward and resolve
the problems we are bringing to light
2017-09-13 3:15 GMT+02:00 Jia Zhai <[EMAIL PROTECTED]>:
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB