+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. Typically, I will either 1) Look at the broker's server.log to see what is printed out at startup OR 2a) look in the broker's config file for explicit overrides 2b) look in at the online docs to figure out defaults 2c) Do some not-that-hard mental layering to figure out which value is the right one. Option 1 may not be available, if the server logs have been rotated out. Option 2 is a multi-step process. I wonder if it might be useful to have a "dry-run" mode where Kafka would parse its config file, calculate its config (using the defaults and overrides), and then print out the result and exit. This would help with detecting changes in config values from one version to another, without requiring actually launching the broker or closely tracking the docs. And/or, a way to query the running broker and have it dump out its config on demand. The same type of thing also applies to topic configuration. ./bin/kafka-configs.sh --describe can be used to look up overrides, but I still have to cross reference the broker config (by doing the above) to figure out how a topic is actually configured. Users could then use that functionality to quickly get an idea of how a new version's configuration has changed, compared to what they are currently running. I know such a thing is out of scope for this KIP. I just wanted to mention it, because it's related to changing of default values (and being aware of changes). -James > On Jan 4, 2017, at 11:51 AM, Rajini Sivaram <rajinisiva...@gmail.com> wrote: > > +1 > > On Wed, Jan 4, 2017 at 1:49 AM, Becket Qin <becket....@gmail.com> wrote: > >> +1 >> >> On Tue, Jan 3, 2017 at 5:41 PM, Joel Koshy <jjkosh...@gmail.com> wrote: >> >>> +1 >>> >>> On Tue, Jan 3, 2017 at 10:54 AM, Ben Stopford <b...@confluent.io> 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 availability over data loss. >>>> >>>> This would mean clusters wishing to continue with unclean leader >> election >>>> enabled would need to add the appropriate configuration on upgrade. >>>> >>>> Please let me know if you foresee any issue with this change, agree or >>>> don’t agree. >>>> >>>> https://cwiki.apache.org/confluence/display/KAFKA/%5BWIP%5D+ >>>> KIP-106+-+Change+Default+unclean.leader.election. >>>> enabled+from+True+to+False <https://cwiki.apache.org/conf >>>> luence/display/KAFKA/[WIP]+KIP-106+-+Change+Default+uncle >>>> an.leader.election.enabled+from+True+to+False >>>> <https://cwiki.apache.org/confluence/display/KAFKA/% >>> 5BWIP%5D+KIP-106+-+Change+Default+unclean.leader. >>> election.enabled+from+True+to+False> >>>>> >>>> >>>> Thanks >>>> >>>> B >>>> >>>> Ben Stopford >>>> Confluent, http://www.confluent.io <http://www.confluent.io/> >>>> >>>> >>>> >>>> >>> >>
