Hi Dong, Thanks for your reply. See inline.
On Mon, Sep 5, 2016 at 11:28 PM, Dong Lin <lindon...@gmail.com> wrote: > Yes, user has the option to manually set the cluster.id by directly > setting > the znode. But the KIP doesn't provide script for doing this. That is correct. And intentionally, as discussed previously. > Unlike reading cluster.id from broker, this approach doesn't allow you to > persist > the cluster.id in case of cluster migration and znode deletion. > Right, this is consistent with how we store the broker sequence id, leaders and ACLs (if you use the built-in authorizer) solely in ZooKeeper. Something that we can improve later (via a broker config or meta.properties). In case of zookeeper migration or znode deletion, you can read the > cluster.id from previous log. But log is not a good place to persist > anything you need because it is not persisted in any repository. Reading a > config value from log for recovery also appears adhoc. > Yes, agreed. This is just a workaround in the catastrophic event that you lose your ZooKeeper ensemble. I agree that in terms of implementation you can add the cluster.id config > value in a future KIP without affecting this KIP. But why couldn't we do it > altogether if it is not too hard and if this adds value on top of existing > proposal? I think we are encouraged to think beyond the existing design of > the KIP to see if it can serve its target use-case better, if the > improvement doesn't require too much additional work. Readability and > ability to persist cluster.id in config seems very useful to the use-case > described in the KIP. > > I am just trying to contribute here by providing the review. If you think > the benefits above is trivial and doesn't have to be included in this KIP, > I am OK with that. Thanks for all the discussion. > We definitely believe in the usefulness of human readable cluster ids. We just think that it would be confusing to have 2 ways of doing it and we think that being able to freely change the human readable cluster id without negative consequences is a worthy goal (and hence the idea of an auto-generated one + a changeable human readable one). At the same time, we would like to ship the foundation (the current KIP) sooner than it would take us to work out all the details of phase 2, discuss them, reach agreement and implement them. And since the foundation is needed in either case, it seemed like a win-win to do it incrementally. If the community agrees and we ship this KIP first, then I very much hope you will be part of the discussion on the KIP for the human readable id. Thanks for sticking with us through this long mailing list thread by the way. :) Ismael
