Great! KIP updated.
El vie., 24 feb. 2017 a las 18:22, Matthias J. Sax (<matth...@confluent.io>)
escribió:
> I like this!
>
> --by-duration and --shift-by
>
>
> -Matthias
>
> On 2/24/17 12:57 AM, Jorge Esteban Quilcate Otoya wrote:
> > Renaming to --by-duration LGTM
> >
> > Not sure about changing it to --shift-by-duration because we could end up
> > with the same redundancy as before with reset: --reset-offsets
> > --reset-to-*.
> >
> > Maybe changing --shift-offset-by to --shift-by 'n' could make it
> consistent
> > enough?
> >
> >
> > El vie., 24 feb. 2017 a las 6:39, Matthias J. Sax (<
> matth...@confluent.io>)
> > escribió:
> >
> >> I just read the update KIP once more.
> >>
> >> I would suggest to rename --to-duration to --by-duration
> >>
> >> Or as a second idea, rename --to-duration to --shift-by-duration and at
> >> the same time rename --shift-offset-by to --shift-by-offset
> >>
> >> Not sure what the best option is, but naming would be more consistent
> IMHO.
> >>
> >>
> >>
> >> -Matthias
> >>
> >> On 2/23/17 4:42 PM, Jorge Esteban Quilcate Otoya wrote:
> >>> Hi All,
> >>>
> >>> If there are no more concerns, I'd like to start vote for this KIP.
> >>>
> >>> Thanks!
> >>> Jorge.
> >>>
> >>> El jue., 23 feb. 2017 a las 22:50, Jorge Esteban Quilcate Otoya (<
> >>> quilcate.jo...@gmail.com>) escribió:
> >>>
> >>>> Oh ok :)
> >>>>
> >>>> So, we can keep `--topic t1:1,2,3`
> >>>>
> >>>> I think with this one we have most of the feedback applied. I will
> >> update
> >>>> the KIP with this change.
> >>>>
> >>>> El jue., 23 feb. 2017 a las 22:38, Matthias J. Sax (<
> >> matth...@confluent.io>)
> >>>> escribió:
> >>>>
> >>>> Sounds reasonable.
> >>>>
> >>>> If we have multiple --topic arguments, it does also not matter if we
> use
> >>>> t1:1,2 or t2=1,2
> >>>>
> >>>> I just suggested '=' because I wanted use ':' to chain multiple
> topics.
> >>>>
> >>>>
> >>>> -Matthias
> >>>>
> >>>> On 2/23/17 10:49 AM, Jorge Esteban Quilcate Otoya wrote:
> >>>>> Yeap, `--topic t1=1,2`LGTM
> >>>>>
> >>>>> Don't have idea neither about getting rid of repeated --topic, but
> >>>> --group
> >>>>> is also repeated in the case of deletion, so it could be ok to have
> >>>>> repeated --topic arguments.
> >>>>>
> >>>>> El jue., 23 feb. 2017 a las 19:14, Matthias J. Sax (<
> >>>> matth...@confluent.io>)
> >>>>> escribió:
> >>>>>
> >>>>>> So you suggest to merge "scope options" --topics, --topic, and
> >>>>>> --partitions into a single option? Sound good to me.
> >>>>>>
> >>>>>> I like the compact way to express it, ie,
> topicname:list-of-partitions
> >>>>>> with "all partitions" if not partitions are specified. It's quite
> >>>>>> intuitive to use.
> >>>>>>
> >>>>>> Just wondering, if we could get rid of the repeated --topic option;
> >> it's
> >>>>>> somewhat verbose. Have no good idea though who to improve it.
> >>>>>>
> >>>>>> If you concatenate multiple topic, we need one more character that
> is
> >>>>>> not allowed in topic names to separate the topics:
> >>>>>>
> >>>>>>> invalidChars = {'/', '\\', ',', '\u0000', ':', '"', '\'', ';', '*',
> >>>>>> '?', ' ', '\t', '\r', '\n', '='};
> >>>>>>
> >>>>>> maybe
> >>>>>>
> >>>>>> --topics t1=1,2,3:t2:t3=3
> >>>>>>
> >>>>>> use '=' to specify partitions (instead of ':' as you proposed) and
> ':'
> >>>>>> to separate topics? All other characters seem to be worse to use to
> >> me.
> >>>>>> But maybe you have a better idea.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> -Matthias
> >>>>>>
> >>>>>>
> >>>>>> On 2/23/17 3:15 AM, Jorge Esteban Quilcate Otoya wrote:
> >>>>>>> @Matthias about the point 9:
> >>>>>>>
> >>>>>>> What about keeping only the --topic option, and support this
> format:
> >>>>>>>
> >>>>>>> `--topic t1:0,1,2 --topic t2 --topic t3:2`
> >>>>>>>
> >>>>>>> In this case topics t1, t2, and t3 will be selected: topic t1 with
> >>>>>>> partitions 0,1 and 2; topic t2 with all its partitions; and topic
> t3,
> >>>>>> with
> >>>>>>> only partition 2.
> >>>>>>>
> >>>>>>> Jorge.
> >>>>>>>
> >>>>>>> El mar., 21 feb. 2017 a las 11:11, Jorge Esteban Quilcate Otoya (<
> >>>>>>> quilcate.jo...@gmail.com>) escribió:
> >>>>>>>
> >>>>>>>> Thanks for the feedback Matthias.
> >>>>>>>>
> >>>>>>>> * 1. You're right. I'll reorder the scenarios.
> >>>>>>>>
> >>>>>>>> * 2. Agree. I'll update the KIP.
> >>>>>>>>
> >>>>>>>> * 3. I like it, updating to `reset-offsets`
> >>>>>>>>
> >>>>>>>> * 4. Agree, removing the `reset-` part
> >>>>>>>>
> >>>>>>>> * 5. Yes, 1.e option without --execute or --export will print out
> >>>>>> current
> >>>>>>>> offset, and the new offset, that will be the same. The use-case of
> >>>> this
> >>>>>>>> option is to use it in combination with --export mostly and have a
> >>>>>> current
> >>>>>>>> 'checkpoint' to reset later. I will add to the KIP how the output
> >>>> should
> >>>>>>>> looks like.
> >>>>>>>>
> >>>>>>>> * 6. Considering 4., I will update it to `--to-offset`
> >>>>>>>>
> >>>>>>>> * 7. I like the idea to unify these options (plus, minus).
> >>>>>>>> `shift-offsets-by` is a good option, but I will like some more
> >>>> feedback
> >>>>>>>> here about the name. I will update the KIP in the meantime.
> >>>>>>>>
> >>>>>>>> * 8. Yes, discussed in 9.
> >>>>>>>>
> >>>>>>>> * 9. Agree. I'll love some feedback here. `topic` is already used
> by
> >>>>>>>> `delete`, and we can add `--all-topics` to consider all
> >>>>>> topics/partitions
> >>>>>>>> assigned to a group. How could we define specific
> topics/partitions?
> >>>>>>>>
> >>>>>>>> * 10. Haven't thought about it, but make sense.
> >>>>>>>> <topic>,<partition>,<offset> would be enough.
> >>>>>>>>
> >>>>>>>> * 11. Agree. Solved with 10.
> >>>>>>>>
> >>>>>>>> Also, I have a couple of changes to mention:
> >>>>>>>>
> >>>>>>>> 1. I have add a reference to the branch where I'm working on this
> >> KIP.
> >>>>>>>>
> >>>>>>>> 2. About the period scenario `--to-period`. I will change it to
> >>>>>>>> `--to-duration` given that duration (
> >>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html
> )
> >>>>>>>> follows this format: 'PnDTnHnMnS' and does not consider daylight
> >>>> saving
> >>>>>>>> efects.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> El mar., 21 feb. 2017 a las 2:47, Matthias J. Sax (<
> >>>>>> matth...@confluent.io>)
> >>>>>>>> escribió:
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> thanks for updating the KIP. Couple of follow up comments:
> >>>>>>>>
> >>>>>>>> * Nit: Why is "Reset to Earliest" and "Reset to Latest" a "reset
> by
> >>>>>>>> time" option -- IMHO it belongs to "reset by position"?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> * Nit: Description of "Reset to Earliest"
> >>>>>>>>
> >>>>>>>>> using Kafka Consumer's `auto.offset.reset` to `earliest`
> >>>>>>>>
> >>>>>>>> I think this is strictly speaking not correct (as
> auto.offset.reset
> >>>> only
> >>>>>>>> triggered if no valid offset is found, but this tool explicitly
> >>>> modified
> >>>>>>>> committed offset), and should be phrased as
> >>>>>>>>
> >>>>>>>>> using Kafka Consumer's #seekToBeginning()
> >>>>>>>>
> >>>>>>>> -> similar issue for description of "Reset to Latest"
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> * Main option: rename to --reset-offsets (plural instead of
> >> singular)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> * Scenario Options: I would remove "reset" from all options,
> because
> >>>> the
> >>>>>>>> main argument "--reset-offset" says already what to do:
> >>>>>>>>
> >>>>>>>>> bin/kafka-consumer-groups.sh --reset-offset --reset-to-datetime
> XXX
> >>>>>>>>
> >>>>>>>> better (IMHO):
> >>>>>>>>
> >>>>>>>>> bin/kafka-consumer-groups.sh --reset-offsets --to-datetime XXX
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> * Option 1.e ("print and export current offset") is not intuitive
> to
> >>>> use
> >>>>>>>> IMHO. The main option is "--reset-offset" but nothing happens if
> no
> >>>>>>>> scenario is specified. It is also not specified, what the output
> >>>> should
> >>>>>>>> look like?
> >>>>>>>>
> >>>>>>>> Furthermore, --describe should actually show currently committed
> >>>> offset
> >>>>>>>> for a group. So it seems to be redundant to have the same option
> in
> >>>>>>>> --reset-offsets
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> * Option 2.a: I would rename to "--reset-to-offset" (or
> considering
> >>>> the
> >>>>>>>> comment above to "--to-offset")
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> * Option 2.b and 2.c: I would unify to "--shift-offsets-by" (or
> >>>> similar)
> >>>>>>>> and accept positive/negative values
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> * About Scope "all": maybe it's better to have an option
> >>>> "--all-topics"
> >>>>>>>> (or similar). IMHO explicit arguments are preferable over implicit
> >>>>>>>> setting to guard again accidental miss use of the tool.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> * Scope: I also think, that "--topic" (singular) and "--topics"
> >>>> (plural)
> >>>>>>>> are too similar and easy to use in a wrong way (ie, mix up) --
> maybe
> >>>> we
> >>>>>>>> can have two options that are easier to distinguish.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> * I still think that JSON is not the best format (it's too
> >>>> verbose/hard
> >>>>>>>> to write for humans from scratch). A simple CSV format with
> implicit
> >>>>>>>> schema (topic,partition,offset) would be sufficient.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> * Why does the JSON contain "group_id" field -- there is parameter
> >>>>>>>> "--group" to specify the group ID. Would one overwrite the other
> >> (what
> >>>>>>>> order) or would there be an error if "--group" is used in
> >> combination
> >>>>>>>> with "--reset-from-file"?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> -Matthias
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 2/17/17 6:43 AM, Jorge Esteban Quilcate Otoya wrote:
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> according to the feedback, I've updated the KIP:
> >>>>>>>>>
> >>>>>>>>> - We have added and ordered the scenarios, scopes and executions
> of
> >>>> the
> >>>>>>>>> Reset Offset tool.
> >>>>>>>>> - Consider it as an extension to the current
> `ConsumerGroupCommand`
> >>>>>> tool
> >>>>>>>>> - Execution will be possible without generating JSON files.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-122%3A+Add+Reset+Consumer+Group+Offsets+tooling
> >>>>>>>>>
> >>>>>>>>> Looking forward to your feedback!
> >>>>>>>>>
> >>>>>>>>> Jorge.
> >>>>>>>>>
> >>>>>>>>> El mié., 8 feb. 2017 a las 23:23, Jorge Esteban Quilcate Otoya (<
> >>>>>>>>> quilcate.jo...@gmail.com>) escribió:
> >>>>>>>>>
> >>>>>>>>>> Great. I think I got the idea. What about this options:
> >>>>>>>>>>
> >>>>>>>>>> Scenarios:
> >>>>>>>>>>
> >>>>>>>>>> 1. Current status
> >>>>>>>>>>
> >>>>>>>>>> ´kafka-consumer-groups.sh --reset-offset --group cg1´
> >>>>>>>>>>
> >>>>>>>>>> 2. To Datetime
> >>>>>>>>>>
> >>>>>>>>>> ´kafka-consumer-groups.sh --reset-offset --group cg1
> >>>>>> --reset-to-datetime
> >>>>>>>>>> 2017-01-01T00:00:00.000´
> >>>>>>>>>>
> >>>>>>>>>> 3. To Period
> >>>>>>>>>>
> >>>>>>>>>> ´kafka-consumer-groups.sh --reset-offset --group cg1
> >>>> --reset-to-period
> >>>>>>>> P2D´
> >>>>>>>>>>
> >>>>>>>>>> 4. To Earliest
> >>>>>>>>>>
> >>>>>>>>>> ´kafka-consumer-groups.sh --reset-offset --group cg1
> >>>>>>>> --reset-to-earliest´
> >>>>>>>>>>
> >>>>>>>>>> 5. To Latest
> >>>>>>>>>>
> >>>>>>>>>> ´kafka-consumer-groups.sh --reset-offset --group cg1
> >>>>>> --reset-to-latest´
> >>>>>>>>>>
> >>>>>>>>>> 6. Minus 'n' offsets
> >>>>>>>>>>
> >>>>>>>>>> ´kafka-consumer-groups.sh --reset-offset --group cg1
> --reset-minus
> >>>> n´
> >>>>>>>>>>
> >>>>>>>>>> 7. Plus 'n' offsets
> >>>>>>>>>>
> >>>>>>>>>> ´kafka-consumer-groups.sh --reset-offset --group cg1
> --reset-plus
> >> n´
> >>>>>>>>>>
> >>>>>>>>>> 8. To specific offset
> >>>>>>>>>>
> >>>>>>>>>> ´kafka-consumer-groups.sh --reset-offset --group cg1 --reset-to
> x´
> >>>>>>>>>>
> >>>>>>>>>> Scopes:
> >>>>>>>>>>
> >>>>>>>>>> a. All topics used by Consumer Group
> >>>>>>>>>>
> >>>>>>>>>> Don't specify --topics
> >>>>>>>>>>
> >>>>>>>>>> b. Specific List of Topics
> >>>>>>>>>>
> >>>>>>>>>> Add list of values in --topics t1,t2,tn
> >>>>>>>>>>
> >>>>>>>>>> c. One Topic, all Partitions
> >>>>>>>>>>
> >>>>>>>>>> Add one topic and no partitions values: --topic t1
> >>>>>>>>>>
> >>>>>>>>>> d. One Topic, List of Partitions
> >>>>>>>>>>
> >>>>>>>>>> Add one topic and partitions values: --topic t1 --partitions
> 0,1,2
> >>>>>>>>>>
> >>>>>>>>>> About Reset Plan (JSON file):
> >>>>>>>>>>
> >>>>>>>>>> I think is still valid to have the option to persist reset
> >>>>>> configuration
> >>>>>>>>>> as a file, but I agree to give the option to run the tool
> without
> >>>>>> going
> >>>>>>>>>> down to the JSON file.
> >>>>>>>>>>
> >>>>>>>>>> Execution options:
> >>>>>>>>>>
> >>>>>>>>>> 1. Without execution argument (No args):
> >>>>>>>>>>
> >>>>>>>>>> Print out results (reset plan)
> >>>>>>>>>>
> >>>>>>>>>> 2. With --execute argument:
> >>>>>>>>>>
> >>>>>>>>>> Run reset process
> >>>>>>>>>>
> >>>>>>>>>> 3. With --output argument:
> >>>>>>>>>>
> >>>>>>>>>> Save result in a JSON format.
> >>>>>>>>>>
> >>>>>>>>>> 4. Only with --execute option and --reset-file (path to JSON)
> >>>>>>>>>>
> >>>>>>>>>> Reset based on file
> >>>>>>>>>>
> >>>>>>>>>> 4. Only with --verify option and --reset-file (path to JSON)
> >>>>>>>>>>
> >>>>>>>>>> Verify file values with current offsets
> >>>>>>>>>>
> >>>>>>>>>> I think we can remove --generate-and-execute because is a bit
> >>>> clumsy.
> >>>>>>>>>>
> >>>>>>>>>> With this options we will be able to execute with manual JSON
> >>>>>>>>>> configuration.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> El mié., 8 feb. 2017 a las 22:43, Ben Stopford (<
> b...@confluent.io
> >>> )
> >>>>>>>>>> escribió:
> >>>>>>>>>>
> >>>>>>>>>> Yes - using a tool like this to skip a set of consumer groups
> >> over a
> >>>>>>>>>> corrupt/bad message is definitely appealing.
> >>>>>>>>>>
> >>>>>>>>>> B
> >>>>>>>>>>
> >>>>>>>>>> On Wed, Feb 8, 2017 at 9:37 PM Gwen Shapira <g...@confluent.io>
> >>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> I like the --reset-to-earliest and --reset-to-latest. In
> general,
> >>>>>>>>>>> since the JSON route is the most challenging for users, we want
> >> to
> >>>>>>>>>>> provide a lot of ways to do useful things without going there.
> >>>>>>>>>>>
> >>>>>>>>>>> Two things that can help:
> >>>>>>>>>>>
> >>>>>>>>>>> 1. A lot of times, users want to skip few messages that cause
> >>>> issues
> >>>>>>>>>>> and continue. maybe just specifying the topic, partition and
> >> delta
> >>>>>>>>>>> will be better than having to find the offset and write a JSON
> >> and
> >>>>>>>>>>> validate the JSON etc.
> >>>>>>>>>>>
> >>>>>>>>>>> 2. Thinking if there are other common use-cases that we can
> make
> >>>> easy
> >>>>>>>>>>> rather than just one generic but not very usable method.
> >>>>>>>>>>>
> >>>>>>>>>>> Gwen
> >>>>>>>>>>>
> >>>>>>>>>>> On Wed, Feb 8, 2017 at 3:25 AM, Jorge Esteban Quilcate Otoya
> >>>>>>>>>>> <quilcate.jo...@gmail.com> wrote:
> >>>>>>>>>>>> Thanks for the feedback!
> >>>>>>>>>>>>
> >>>>>>>>>>>> @Onur, @Gwen:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Agree. Actually at the first draft I considered to have it
> >> inside
> >>>>>>>>>>>> ´kafka-consumer-groups.sh´, but I decide to propose it as a
> >>>>>> standalone
> >>>>>>>>>>> tool
> >>>>>>>>>>>> to describe it clearly and focus it on reset functionality.
> >>>>>>>>>>>>
> >>>>>>>>>>>> But now that you mentioned, it does make sense to have it in
> >>>>>>>>>>>> ´kafka-consumer-groups.sh´. How would be a consistent way to
> >>>>>> introduce
> >>>>>>>>>>> it?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Maybe something like this:
> >>>>>>>>>>>>
> >>>>>>>>>>>> ´kafka-consumer-groups.sh --reset-offset --generate --group
> cg1
> >>>>>>>>>> --topics
> >>>>>>>>>>> t1
> >>>>>>>>>>>> --reset-from 2017-01-01T00:00:00.000 --output plan.json´
> >>>>>>>>>>>>
> >>>>>>>>>>>> ´kafka-consumer-groups.sh --reset-offset --verify
> >>>> --reset-json-file
> >>>>>>>>>>>> plan.json´
> >>>>>>>>>>>>
> >>>>>>>>>>>> ´kafka-consumer-groups.sh --reset-offset --execute
> >>>> --reset-json-file
> >>>>>>>>>>>> plan.json´
> >>>>>>>>>>>>
> >>>>>>>>>>>> ´kafka-consumer-groups.sh --reset-offset
> --generate-and-execute
> >>>>>>>> --group
> >>>>>>>>>>> cg1
> >>>>>>>>>>>> --topics t1 --reset-from 2017-01-01T00:00:00.000´
> >>>>>>>>>>>>
> >>>>>>>>>>>> @Gwen:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> It looks exactly like the replica assignment tool
> >>>>>>>>>>>>
> >>>>>>>>>>>> It was influenced by ;-) I use the generate-verify-execute
> >> process
> >>>>>>>> here
> >>>>>>>>>>> to
> >>>>>>>>>>>> make sure user will be aware of the result of this operation.
> At
> >>>> the
> >>>>>>>>>>>> beginning we considered only add a couple of options to
> Consumer
> >>>>>> Group
> >>>>>>>>>>>> Command:
> >>>>>>>>>>>>
> >>>>>>>>>>>> --rewind-to-timestamp and --rewind-to-period
> >>>>>>>>>>>>
> >>>>>>>>>>>> @Onur:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> You can actually get away with overriding while members of
> the
> >>>>>> group
> >>>>>>>>>>> are live
> >>>>>>>>>>>> with method 2 by using group information from
> >>>> DescribeGroupsRequest.
> >>>>>>>>>>>>
> >>>>>>>>>>>> This means that we need to have Consumer Group stopped before
> >>>>>>>> executing
> >>>>>>>>>>> and
> >>>>>>>>>>>> start a new consumer internally to do this? Therefore, we
> won't
> >> be
> >>>>>>>> able
> >>>>>>>>>>> to
> >>>>>>>>>>>> consider executing reset when ConsumerGroup is active? (trying
> >> to
> >>>>>>>>>> relate
> >>>>>>>>>>> it
> >>>>>>>>>>>> with @Dong 5th question)
> >>>>>>>>>>>>
> >>>>>>>>>>>> @Dong:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Should we allow user to use wildcard to reset offset of all
> >>>> groups
> >>>>>>>>>> for a
> >>>>>>>>>>>> given topic as well?
> >>>>>>>>>>>>
> >>>>>>>>>>>> I haven't thought about this scenario. Could be interesting.
> >>>>>> Following
> >>>>>>>>>>> the
> >>>>>>>>>>>> recommendation to add it into Consumer Group Command, in this
> >> case
> >>>>>>>>>> Group
> >>>>>>>>>>>> argument will be optional if there are only 1 topic. I think
> for
> >>>>>>>>>> multiple
> >>>>>>>>>>>> topic won't be that useful.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Should we allow user to specify timestamp per topic partition
> >> in
> >>>>>> the
> >>>>>>>>>>> json
> >>>>>>>>>>>> file as well?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Don't think this could be a valid from the tool, but if Reset
> >> Plan
> >>>>>> is
> >>>>>>>>>>>> generated, and user want to set the offset for a specific
> >>>> partition
> >>>>>> to
> >>>>>>>>>>>> other offset (eventually based on another timestamp), and
> >> execute
> >>>>>> it,
> >>>>>>>>>> it
> >>>>>>>>>>>> will be up to her/him.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Should the script take some credential file to make sure that
> >>>> this
> >>>>>>>>>>>> operation is authenticated given the potential impact of this
> >>>>>>>>>> operation?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Haven't tried to secure brokers yet, but the tool should
> support
> >>>>>>>>>>>> authorization if it's enabled in the broker.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Should we provide constant to reset committed offset to
> >>>>>>>>>> earliest/latest
> >>>>>>>>>>>> offset of a partition, e.g. -1 indicates earliest offset and
> -2
> >>>>>>>>>> indicates
> >>>>>>>>>>>> latest offset.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I will go for something like ´--reset-to-earliest´ and
> >>>>>>>>>>> ´--reset-to-latest´
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Should we allow dynamic change of the comitted offset when
> >>>> consumer
> >>>>>>>>>> are
> >>>>>>>>>>>> running, such that consumer will seek to the newly committed
> >>>> offset
> >>>>>>>> and
> >>>>>>>>>>>> start consuming from there?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Not sure about this. I will recommend to keep it simple and
> ask
> >>>> user
> >>>>>>>> to
> >>>>>>>>>>>> stop consumers first. But I would considered it if the
> >> trade-offs
> >>>>>> are
> >>>>>>>>>>>> clear.
> >>>>>>>>>>>>
> >>>>>>>>>>>> @Matthias
> >>>>>>>>>>>>
> >>>>>>>>>>>> Added :). And thanks a lot for your help to define this KIP!
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> El mié., 8 feb. 2017 a las 7:47, Gwen Shapira (<
> >> g...@confluent.io
> >>>>> )
> >>>>>>>>>>>> escribió:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> As long as the CLI is a bit consistent? Like, not just
> adding 3
> >>>>>>>>>>>>> arguments and a JSON parser to the existing tool, right?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Tue, Feb 7, 2017 at 10:29 PM, Onur Karaman
> >>>>>>>>>>>>> <onurkaraman.apa...@gmail.com> wrote:
> >>>>>>>>>>>>>> I think it makes sense to just add the feature to
> >>>>>>>>>>>>> kafka-consumer-groups.sh
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Tue, Feb 7, 2017 at 10:24 PM, Gwen Shapira <
> >>>> g...@confluent.io>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Thanks for the KIP. I'm super happy about adding the
> >>>> capability.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I hate the interface, though. It looks exactly like the
> >> replica
> >>>>>>>>>>>>>>> assignment tool. A tool everyone loves so much that there
> are
> >>>>>>>>>>> multiple
> >>>>>>>>>>>>>>> projects, open and closed, that try to fix it.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Can we swap it with something that looks a bit more like
> the
> >>>>>>>>>> consumer
> >>>>>>>>>>>>>>> group tool? or the kafka streams reset tool? Consistency is
> >>>>>> helpful
> >>>>>>>>>>> in
> >>>>>>>>>>>>>>> such cases. I spent some time learning existing tools and
> >>>>>> learning
> >>>>>>>>>>> yet
> >>>>>>>>>>>>>>> another one is a deterrent.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Gwen
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Tue, Feb 7, 2017 at 6:43 PM, Jorge Esteban Quilcate
> Otoya
> >>>>>>>>>>>>>>> <quilcate.jo...@gmail.com> wrote:
> >>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I would like to propose a KIP to Add a tool to Reset
> >> Consumer
> >>>>>>>>>> Group
> >>>>>>>>>>>>>>> Offsets.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> >>>>>>>>>>>>>>> 122%3A+Add+a+tool+to+Reset+Consumer+Group+Offsets
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Please, take a look at the proposal and share your
> feedback.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>> Jorge.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>> Gwen Shapira
> >>>>>>>>>>>>>>> Product Manager | Confluent
> >>>>>>>>>>>>>>> 650.450.2760 <(650)%20450-2760> <(650)%20450-2760>
> <(650)%20450-2760>
> >> <(650)%20450-2760>
> >>>> <(650)%20450-2760>
> >>>>>> <(650)%20450-2760>
> >>>>>>>> <(650)%20450-2760>
> >>>>>>>>>> <(650)%20450-2760> | @gwenshap
> >>>>>>>>>>>>>>> Follow us: Twitter | blog
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> Gwen Shapira
> >>>>>>>>>>>>> Product Manager | Confluent
> >>>>>>>>>>>>> 650.450.2760 <(650)%20450-2760> <(650)%20450-2760>
> <(650)%20450-2760>
> >> <(650)%20450-2760>
> >>>> <(650)%20450-2760>
> >>>>>> <(650)%20450-2760>
> >>>>>>>> <(650)%20450-2760>
> >>>>>>>>>> <(650)%20450-2760> | @gwenshap
> >>>>>>>>>>>>> Follow us: Twitter | blog
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Gwen Shapira
> >>>>>>>>>>> Product Manager | Confluent
> >>>>>>>>>>> 650.450.2760 <(650)%20450-2760> <(650)%20450-2760>
> <(650)%20450-2760>
> >> <(650)%20450-2760>
> >>>> <(650)%20450-2760>
> >>>>>> <(650)%20450-2760> <(650)%20450-2760>
> >>>>>>>> | @gwenshap
> >>>>>>>>>>> Follow us: Twitter | blog
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>
>
