You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

This page is meant as a template for writing a KIP. To create a KIP choose Tools->Copy on this page and modify with your content and replace the heading with the next KIP number and a description of your issue. Replace anything in italics with your own description.

Status

Current state: [One of "Under Discussion", "Accepted", "Rejected"]

Discussion thread: here

JIRA: here

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Currently all the tools in Kafka we have three flavor of command line arguments:

  1. command line arguments using dot, e.g. --consumer.config
  2. command line arguments using dash --broker-list
  3. command line arguments using position 

2) and 3) conforms to Unix statndard while 1) does not. We want to standardize them.

It would also be good if we can check whether it makes sense to change the interface so that the tools would be easier to use. e.g. mirror maker always require config files for producer and consumer even when most people might just use default settings.

Public Interfaces

The following list summarizes the flavor of each tool we have now in Kafka. The argument style are marked in parentheses using the number in previous section.

ConsoleConsumer(1 & 2)

ConsoleProducer(2)

ConsumerOffsetChecker(2)

ConsumerPerformance(2)

DumpLogSegment(2)

ExportZkOffsets(2)

GetOffsetShell(2)

ImportZkOffsets(2)

JmxTool(2)

MirrorMaker(1)

ProducerPerformance - scala (2)

ProducerPerformance - java (3)

ReplayLogProducer(2)

ReplicaVerificationTool(2)

SimpleConsumerPerformance(2)

SimpleConsumerShell(2)

StateChangeLogMerger(2)

TestEndToEndLatency(3)

TestLogCleaning(2)

UpdateOffsetsInZk(3)

VerifyConsumerRebalacne(1)

Proposed Changes

Change ConsoleConsumer, MirrorMaker, VerifyConsumerRebalance tools to use style 2).

Review other tools to see if the arguments are still valid and whether there is space to improve.

Compatibility, Deprecation, and Migration Plan

  • What impact (if any) will there be on existing users?
  • If we are changing behavior how will we phase out the older behavior?
  • If we need special migration tools, describe them here.
  • When will we remove the existing behavior?

Rejected Alternatives

None

  • No labels