Thanks for clarifying the upgrade path. +1 for this proposal, it will greatly reduce errors resulting from configuration mismatches.
On Thu, Jan 22, 2015 at 8:40 AM, Joe Stein <joe.st...@stealth.ly> wrote: > Deployment proposal: > > 1. If global configuration isn't being used, do what you do today (there > should be configuration brokers.admin.global.configuration=true > [default=false]. This works for the upgrade. Once all brokers are upgraded > proceed. > 2. if the global config is used then only some (host, port) will be able > to be overridden in property for a single broker. There will always be > configs that make sense for a single broker to be able to override. In the > most case so far going through them there were few though. We should have > this clear in the code for how to update those fields. This latter point is > tied into https://issues.apache.org/jira/browse/KAFKA-1845 closely. > 3. If the property is not set in storage mechanism then use default from > how we manage the configuration definitions. > > > On Thu, Jan 22, 2015 at 11:16 AM, Harsha <ka...@harsha.io> wrote: > >> Hi Joe, >> How does initial deployments will look in this environment. I guess >> users will deploy the kafka cluster and it will be running with >> defaults and they can use a command line tool to update the >> configs?. >> I think you need to update the JIRA and mailing list thread links on the >> KIP page. >> Thanks, >> Harsha >> >> >> >> On Wed, Jan 21, 2015, at 10:34 PM, Joe Stein wrote: >> > Created a KIP >> > >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-5+-+Broker+Configuration+Management >> > >> > JIRA https://issues.apache.org/jira/browse/KAFKA-1786 >> > >> > /******************************************* >> > Joe Stein >> > Founder, Principal Consultant >> > Big Data Open Source Security LLC >> > http://www.stealth.ly >> > Twitter: @allthingshadoop <http://www.twitter.com/allthingshadoop> >> > ********************************************/ >>
