On Mon, Sep 5, 2016 at 10:41 PM, Ismael Juma wrote:
> I will update the KIP to make this point clearer.
>
Done.
Ismael
Hi Dong,
Thanks for your reply. See inline.
On Mon, Sep 5, 2016 at 11:28 PM, Dong Lin 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 previou
Hey Ismael,
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. 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.
I
Hi Dong,
A few clarifications below.
On Mon, Sep 5, 2016 at 7:21 PM, Dong Lin wrote:
>
> I think you are saying that we can stop our discussion and follow simply
> take a vote where the majority decides. I don't think this is a good way to
> find the best design for a KIP and the discussion seem
Ismael,
I think you are saying that we can stop our discussion and follow simply
take a vote where the majority decides. I don't think this is a good way to
find the best design for a KIP and the discussion seems to be useless. It
doesn't seem like anyone else is interested to join this discussion
Dong,
Sumit responded to a number of points already, so I will try to be brief.
See inline.
Also, it may just be possible that we won't reach agreement. In that case,
a vote may be a way to figure out if people feel that this proposal adds
value in its current form or not.
On Mon, Sep 5, 2016 at
Hey Sumit,
Thanks for your detailed response. Please see my comment inline.
On Sun, Sep 4, 2016 at 10:56 PM, sumit arrawatia
wrote:
> Hi Dong,
>
> Please find my answers inline.
>
> Hopefully they address your concerns this time !
>
> Sumit
>
> On Sun, Sep 4, 2016 at 4:54 PM, Dong Lin wrote:
>
Hi Dong,
Please find my answers inline.
Hopefully they address your concerns this time !
Sumit
On Sun, Sep 4, 2016 at 4:54 PM, Dong Lin wrote:
> Hey Ismael,
>
> Thanks for the explanation Ismael. Please see my comment inline.
>
> On Sun, Sep 4, 2016 at 8:58 AM, Ismael Juma wrote:
>
> > Hi Do
Hey Ismael,
Thanks for the explanation Ismael. Please see my comment inline.
On Sun, Sep 4, 2016 at 8:58 AM, Ismael Juma wrote:
> Hi Dong,
>
> Sorry for the delay, I was offline for 24 hours. Thankfully Sumit was
> around to explain the reasoning for the current approach. From reading the
> thr
Hi Dong,
Sorry for the delay, I was offline for 24 hours. Thankfully Sumit was
around to explain the reasoning for the current approach. From reading the
thread, it seems like it may help to reiterate a few important goals for
the auditing use case where there is a requirement to associate a messa
Hi Flavio,
Thanks for reviewing the KIP. Comments inline.
On Sat, Sep 3, 2016 at 4:48 PM, Flavio Junqueira wrote:
> Thanks for the KIP, Ismael, looks great. I have just a couple of comments
> and questions:
>
> - I assume the znode containing the cluster id is persistent. Is there
> ever the ne
Hey Sumit,
I have no doubt that there are benefits with using tags. But the usage of
tags is actually orthogonal to the usage of cluster.id. I am not sure the
benefits of using tags that you provided can help us decide whether
randomly generated cluster.id is better than readable cluster.id from
c
Hi Dong,
Please find my comments inline.
Hopefully they address your concerns.
Have a great weekend !
Sumit
On Sat, Sep 3, 2016 at 3:17 PM, Dong Lin wrote:
> Hi Sumit,
>
> Please see my comments inline.
>
> On Sat, Sep 3, 2016 at 10:33 AM, sumit arrawatia <
> sumit.arrawa...@gmail.com>
> wrot
Hi Sumit,
Please see my comments inline.
On Sat, Sep 3, 2016 at 10:33 AM, sumit arrawatia
wrote:
> Hi Dong,
>
> Please see my comments inline.
>
> Sumit
>
> On Sat, Sep 3, 2016 at 9:26 AM, Dong Lin wrote:
>
> > Hey Sumit,
> >
> > Thanks Sumit for your explanation. It seems that the concern is
Hi Dong,
Please see my comments inline.
Sumit
On Sat, Sep 3, 2016 at 9:26 AM, Dong Lin wrote:
> Hey Sumit,
>
> Thanks Sumit for your explanation. It seems that the concern is that we can
> not easily change cluster.id if we read this from config. Maybe the KIP
> should also specify the require
Hi Flavio,
I have added some comments inline based on my understanding of the
implementation but Ismael probably can add more to this from an
architectural perspective.
Cheers,
Sumit
On Sat, Sep 3, 2016 at 8:48 AM, Flavio Junqueira wrote:
> Thanks for the KIP, Ismael, looks great. I have just
Hey Sumit,
Thanks Sumit for your explanation. It seems that the concern is that we can
not easily change cluster.id if we read this from config. Maybe the KIP
should also specify the requirement for users to change the cluster.id.
But it seems to me that it is equally straightforward to change cl
Thanks for the KIP, Ismael, looks great. I have just a couple of comments and
questions:
- I assume the znode containing the cluster id is persistent. Is there ever the
need to delete that znode to force a new instance id, and if so, how is it
expected to happen? I'm thinking about a scenario i
Hi Dong,
If you set the cluster.id in the config, the problem is how you
change/update the cluster.id .
You will need to change the all the config files and make sure every one of
them is correct as well as update the ZK metadata. This will require a
reboot/downtime of the entire cluster, wherea
Hey Ismael,
Thanks for your reply. Please see my comment inline.
On Fri, Sep 2, 2016 at 8:28 PM, Ismael Juma wrote:
> Hi Dong,
>
> Thanks for your feedback. Comments inline.
>
> On Thu, Sep 1, 2016 at 7:51 PM, Dong Lin wrote:
> >
> > I share the view with Harsha and would like to understand ho
Hi Dong,
Thanks for your feedback. Comments inline.
On Thu, Sep 1, 2016 at 7:51 PM, Dong Lin wrote:
>
> I share the view with Harsha and would like to understand how the current
> approach of randomly generating cluster.id compares with the approach of
> manually specifying it in meta.properties
Hey Ismael,
Thanks for the KIP.
I share the view with Harsha and would like to understand how the current
approach of randomly generating cluster.id compares with the approach of
manually specifying it in meta.properties.
I think one big advantage of defining it manually in zookeeper is that we
Hi Jun,
Thanks for the feedback. Using `Cluster` was appealing because it has the
information we need and it is already a public class, so we would not need
to introduce a new public class with a potentially confusing name. Having
said that, I agree with your points and I have updated the KIP so t
Ismael,
Thanks for the proposal. It looks good overall. Just a comment below.
We are adding the following interface in ClusterListener and Cluster
includes all brokers' endpoint and the metadata of topic partitions.
void onClusterUpdate(Cluster cluster);
On the broker side, will that method be
Thanks for the feedback Guozhang. Comment inline.
On Wed, Aug 31, 2016 at 2:49 AM, Guozhang Wang wrote:
> About logging / debugging with the cluster id: I think the random UUID
> itself may not be very helpful for human-readable debugging information,
> and we'd better use the cluster name menti
The KIP doc is well written, thanks Ismael!
About logging / debugging with the cluster id: I think the random UUID
itself may not be very helpful for human-readable debugging information,
and we'd better use the cluster name mentioned in future work in logging.
Guozhang
On Tue, Aug 30, 2016 at
Hi Harsha,
It's a good question. If your broker connects to a different zookeeper root
(whether on the same server or not), the outcome depends on whether a
cluster id already exists there. If it does, then that cluster id will be
used. If not, a new cluster id will be generated.
The existing KIP
Hi Gwen,
That's a good point. I updated the KIP to mention that.
Thanks,
Ismael
On Sun, Aug 28, 2016 at 12:47 AM, Gwen Shapira wrote:
> Thanks Ismael, this looks great.
>
> One of the things you mentioned is that cluster ID will be useful in
> log aggregation. Perhaps it makes sense to include
Ismael,
What happens when the cluster.id changes from initial value. Ex,
Users changed their zookeeper.root and now new cluster.id generated. Do you
think it would be useful to store this in meta.properties along with
broker.id. So that we only generate it once and store it in disk.
Tha
Thanks Ismael, this looks great.
One of the things you mentioned is that cluster ID will be useful in
log aggregation. Perhaps it makes sense to include cluster ID in the
log? For example, as one of the things a broker logs after startup?
And ideally clients would log that as well after successful
Hi all,
We've posted "KIP-78: Cluster Id" for discussion:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-78%3A+Cluster+Id
Please take a look. Your feedback is appreciated.
Thanks,
Ismael
31 matches
Mail list logo
