@Dongjin Thanks, you raise some good points. I think the intent here is to try and fix one of the more egregious inconsistencies without increasing the scope too much. We tried the big KIP approach with KIP-14 before and I don't think we made much progress. I think it's reasonable to do this on a case by case basis to avoid a lot of bikeshedding. The name `--bootstrap-sever` is the one the project has generally settled on. It is consistent with the `bootstrap.server` configuration which is used by all the clients.
@Mitch I'd suggest taking this to a vote. -Jason On Fri, Aug 2, 2019 at 5:37 AM Dongjin Lee <dong...@apache.org> wrote: > Hello Mitchel, > > Thanks for the KIP. Sure, This inconsistency is really annoying and causing > lots of confusions. Here are some comments: > > First, there is already a Jira issue about this problem, created by Ismael. > https://issues.apache.org/jira/browse/KAFKA-8507 I added the link to the > KIP. > > Add to this, it seems like this problem is a little bit more complicated > than the first glance - you can see more in the comment I left in the Jira > issue 2 weeks ago. > > *1. Location and parameter parser* > > Most tools are located in kafka.tools or kafka.admin package in the core > module, with jOptSimple as a arguments parser. However, > kafka-verifiable-consumer.sh (VerifiableConsumer) and > kafka-verifiable-producer.sh (VerifiableProducer) are located in > org.apache.kafka.tools package in tools module, with argparse4j as a > parameter parser. For this reason, they do not provide standardized > 'version' parameter. (see KAFKA-8292). > > You can find the implementation of jOptSimple parameter parsing and testing > from the following: > > - > > https://github.com/dongjinleekr/kafka/blob/feature%2FKAFKA-8292/core/src/main/scala/kafka/tools/ProducerPerformance.scala > - > > https://github.com/dongjinleekr/kafka/blob/feature%2FKAFKA-8292/core/src/test/scala/kafka/tools/ProducerPerformanceTest.scala > > *2. Connection name flag* > > Currently, there are three co-existing alternatives in the flags: > > a. broker-list: ConsumerPerformance, ConsoleProducer, etc. > b. bootstrap-server: ConfigCommand, etc. > c. bootstrap-servers: StreamsResetter. > > Before progressing this issue, it would be better to agree with which name > should be the standard. It seems like most of the community agree to > bootstrap-server (b) but, bootstrap-servers (c) deserves consideration - it > is consistent with [ProducerConfig, > ConsumerConfig].BOOTSTRAP_SERVERS_CONFIG. > > How do you think? > > *3. Other consistencies* > > As you can see in the comment, there are more inconsistency problems in the > tools. May I take the tasks except for the tools you are working, as a > follow-up KIP? > > @committers Is this okay? > > Thanks, > Dongjin > > > On Fri, Aug 2, 2019 at 7:15 AM Gwen Shapira <g...@confluent.io> wrote: > > > +1 for the KIP > > > > On Tue, Jul 30, 2019 at 5:25 PM Mitchell <mitche...@gmail.com> wrote: > > > > > > Hello, > > > I have written a proposal to add the command line argument > > > `--bootstrap-server` to 5 of the existing command line tools that do > not > > > currently use `--broker-list` for passing cluster connection > information. > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-499+-+Unify+connection+name+flag+for+command+line+tool > > > > > > Please take a look and let me know what you think. > > > Thanks, > > > -Mitch > > > > > > > > -- > > Gwen Shapira > > Product Manager | Confluent > > 650.450.2760 | @gwenshap > > Follow us: Twitter | blog > > > > > -- > *Dongjin Lee* > > *A hitchhiker in the mathematical world.* > *github: <http://goog_969573159/>github.com/dongjinleekr > <https://github.com/dongjinleekr>linkedin: kr.linkedin.com/in/dongjinleekr > <https://kr.linkedin.com/in/dongjinleekr>speakerdeck: > speakerdeck.com/dongjin > <https://speakerdeck.com/dongjin>* >
