+1
I agree with Gwen that this needs to be well communicated to users. Anyone who
is using the current default may see their brokers start to go exit when they
upgrade to this new version.
On a somewhat related subject, occasionally I'll need to look up how my Kafka
brokers are configured. Typ
+1
On Wed, Jan 4, 2017 at 1:49 AM, Becket Qin wrote:
> +1
>
> On Tue, Jan 3, 2017 at 5:41 PM, Joel Koshy wrote:
>
> > +1
> >
> > On Tue, Jan 3, 2017 at 10:54 AM, Ben Stopford wrote:
> >
> > > Hi All
> > >
> > > Please find the below KIP which proposes changing the setting
> > > unclean.leader.
+1
On Tue, Jan 3, 2017 at 5:41 PM, Joel Koshy wrote:
> +1
>
> On Tue, Jan 3, 2017 at 10:54 AM, Ben Stopford wrote:
>
> > Hi All
> >
> > Please find the below KIP which proposes changing the setting
> > unclean.leader.election.enabled from true to false. The motivation for
> > this change is tha
+1
On Tue, Jan 3, 2017 at 10:54 AM, Ben Stopford wrote:
> Hi All
>
> Please find the below KIP which proposes changing the setting
> unclean.leader.election.enabled from true to false. The motivation for
> this change is that it catches out new Kafka users who don’t realise the
> default favours
+1
On Tue, Jan 3, 2017 at 1:12 PM, Sriram Subramanian wrote:
> +1
>
> On Tue, Jan 3, 2017 at 11:56 AM, Ian Wrigley wrote:
>
> > +1 from me too. When I talk to people in training classes, who are
> > typically much newer to Kafka, they tend to be surprised (and
> > scared/horrified) that the def
+1
On Tue, Jan 3, 2017 at 11:56 AM, Ian Wrigley wrote:
> +1 from me too. When I talk to people in training classes, who are
> typically much newer to Kafka, they tend to be surprised (and
> scared/horrified) that the default is true. Much safer to set it to false
> and let people change it when
+1 from me too. When I talk to people in training classes, who are typically
much newer to Kafka, they tend to be surprised (and scared/horrified) that the
default is true. Much safer to set it to false and let people change it when
they really understand the tradeoffs.
Ian.
---
Ian Wrigley
Di
Big +1.
On Tue, Jan 3, 2017 at 11:22 AM Tom Crayford wrote:
> +1. We've been running it in production for a long time and it's the right
> default.
>
> On Tue, Jan 3, 2017 at 7:17 PM, Ismael Juma wrote:
>
> > Thanks for the KIP, +1 from me.
> >
> > Ismael
> >
> > On 3 Jan 2017 6:54 pm, "Ben Sto
+1. We've been running it in production for a long time and it's the right
default.
On Tue, Jan 3, 2017 at 7:17 PM, Ismael Juma wrote:
> Thanks for the KIP, +1 from me.
>
> Ismael
>
> On 3 Jan 2017 6:54 pm, "Ben Stopford" wrote:
>
> > Hi All
> >
> > Please find the below KIP which proposes chan
Thanks for the KIP, +1 from me.
Ismael
On 3 Jan 2017 6:54 pm, "Ben Stopford" wrote:
> Hi All
>
> Please find the below KIP which proposes changing the setting
> unclean.leader.election.enabled from true to false. The motivation for
> this change is that it catches out new Kafka users who don’t
I strongly support this. I've seen many users and customers
accidentally lose data because they didn't know this configuration
exists. I always support defaulting to "Not lose data" and let the
users who prefer high availability do some extra research. This will
need to be very well documented - bo
Hi All
Please find the below KIP which proposes changing the setting
unclean.leader.election.enabled from true to false. The motivation for this
change is that it catches out new Kafka users who don’t realise the default
favours availability over data loss.
This would mean clusters wishing to
12 matches
Mail list logo
