Hi, I liked the KIP, as it will avoid so many errors which user can make during setup. I have 1 questions here. 1. As default replication factor is set to 3, but if Kafka cluster is setup for one node, then the user needs to override the default configuraion, till then topics will not be created. So, this is the behavior we want to give?
On Mon, May 8, 2017 at 2:25 PM, Konstantine Karantasis < konstant...@confluent.io> wrote: > Thanks a lot for the KIP Randall. This improvement should simplify both > regular deployments and testing! > > A minor comment. Maybe it would be nice to add a note about why there's no > need for the property: config.storage.partitions > I'm mentioning this for the sake of completeness, in case someone notices > this slight asymmetry with respect to the newly introduced config > properties. > > This is by no means a blocking comment. > > Thanks, > Konstantine > > On Fri, May 5, 2017 at 7:18 PM, Randall Hauch <rha...@gmail.com> wrote: > > > Thanks, Gwen. > > > > Switching to low-priority is a great idea. > > > > The default value for the replication factor configuration is 3, since > > that makes sense and is safe for production. Using the default values in > > the example would mean it could only be run against a Kafka cluster with > a > > minimum of 3 nodes. I propose overriding the example's replication factor > > configurations to be 1 so that the examples could be run on any sized > > cluster. > > > > The rejected alternatives mentions why the implementation doesn't try to > > be too smart by calculating the replication factor. > > > > Best regards, > > > > Randall > > > > > On May 5, 2017, at 8:02 PM, Gwen Shapira <g...@confluent.io> wrote: > > > > > > Looks great to me :) > > > > > > Just one note - configurations have levels (which reflect in the docs) > - > > I > > > suggest putting the whole thing as LOW. Most users will never need to > > worry > > > about these. For same reason I recommend leaving them out of the > example > > > config files - we already have issues with users playing with configs > > > without understanding what they are doing and not liking the results. > > > > > >> On Fri, May 5, 2017 at 3:42 PM, Randall Hauch <rha...@gmail.com> > wrote: > > >> > > >> Hi, all. > > >> > > >> I've been working on KAFKA-4667 to change the distributed worker of > > Kafka > > >> Connect to look for the topics used to store connector and task > > >> configurations, offsets, and status, and if those tasks do not exist > to > > >> create them using the new AdminClient. To make this as useful as > > possible > > >> and to minimize the need to still manually create the topics, I > propose > > >> adding several new distributed worker configurations to specify the > > >> partitions and replication factor for these topics, and have outlined > > them > > >> in "KIP-154 Add Kafka Connect configuration properties for creating > > >> internal topics". > > >> > > >> https://cwiki.apache.org/confluence/display/KAFKA/KIP- > > >> 154+Add+Kafka+Connect+configuration+properties+for+ > > >> creating+internal+topics > > >> > > >> Please take a look and provide feedback. Thanks! > > >> > > >> Best regards, > > >> > > >> Randall > > >> > > > > > > > > > > > > -- > > > *Gwen Shapira* > > > Product Manager | Confluent > > > 650.450.2760 | @gwenshap > > > Follow us: Twitter <https://twitter.com/ConfluentInc> | blog > > > <http://www.confluent.io/blog> > > >
