Thanks for clarification Colin!
I like the proposal.
-Matthias
On 3/3/18 2:53 PM, Colin McCabe wrote:
> I agree. --execute is inconsistent with the way UNIX commands normally work.
> Normally, if you don't want something to be executed, you pass something like
> a --dry-run flag. Users
I agree. --execute is inconsistent with the way UNIX commands normally work.
Normally, if you don't want something to be executed, you pass something like a
--dry-run flag. Users expect a command to be run when the run it... that's the
reason why this has created so much confusion for Kafka
Bootstrap servers vs broker list is the biggest hurdle when teaching to
beginners. A standardized set of parameters would incredibly help
On 27 Feb. 2018 9:44 am, "Matthias J. Sax" wrote:
I agree on consistency, too.
However, I am not sure if we should introduce an
I agree on consistency, too.
However, I am not sure if we should introduce an explicit --execute
option. Anybody familiar with Linux tools will expect a command to
execute by default.
Thus, I would suggest to remove --execute for all tools that use this
option atm.
Btw: there is a related Jira:
Hi Jorge,
I agree on being consistent across our tools.
Besides the kafka-consumer-groups and kafka-streams-application-reset, a
couple of other classes to consider adding the --execute options for the
next major release:
1. kafka-preferred-replica-elections
2. kafka-reassign-partitions
3.
Hi all,
Thanks for the feedback.
I have updated the "Compatibility, Deprecation, and Migration Plan" section
to document this to support the rollback. I probably should have handled
this change, as small as it looks, as a new KIP to avoid this issue.
I like Colin's idea about asking for
Yup, agreed.
On Thu, Feb 22, 2018 at 11:46 AM, Ismael Juma wrote:
> Hi Guozhang,
>
> To clarify my comment: any change with a backwards compatibility impact
> should be mentioned in the "Compatibility, Deprecation, and Migration Plan"
> section (in addition to the deprecation
Hi Guozhang,
To clarify my comment: any change with a backwards compatibility impact
should be mentioned in the "Compatibility, Deprecation, and Migration Plan"
section (in addition to the deprecation period and only happening in a
major release as you said).
Ismael
On Thu, Feb 22, 2018 at
I like Colin's suggestion for the longer term. If you don't provide
--dry-run or --execute, then the command will prompt you.
-Jason
On Thu, Feb 22, 2018 at 11:10 AM, Guozhang Wang wrote:
> Just to clarify, the KIP itself has mentioned about the change so the PR
> was not
Just to clarify, the KIP itself has mentioned about the change so the PR
was not un-intentional:
"
3. Keep execution parameters uniform between both tools: It will execute by
default, and have a `dry-run` parameter just show the results. This will
involve change current `ConsumerGroupCommand` to
Perhaps, if the user doesn't pass the --execute flag, the tool should print a
prompt like "would you like to perform this reset?" and wait for a Y / N (or
yes or no) input from the command-line. Then, if the --execute flag is passed,
we skip this. That seems 99% compatible, and also
Yes, let's revert the incompatible changes. There was no mention of
compatibility impact on the KIP and we should ensure that is the case for
1.1.0.
Ismael
On Thu, Feb 22, 2018 at 9:55 AM, Jason Gustafson wrote:
> I know it's a been a while since this vote passed, but I
I know it's a been a while since this vote passed, but I think we need to
reconsider the incompatible changes to the consumer reset tool.
Specifically, we have removed the --execute option without deprecating it
first, and we have changed the default behavior to execute rather than do a
dry run.
Thanks to everyone for your feedback.
KIP has been accepted and discussion is moved to PR.
Cheers,
Jorge.
El lun., 6 nov. 2017 a las 17:31, Rajini Sivaram ()
escribió:
> +1 (binding)
> Thanks for the KIP, Jorge.
>
> Regards,
>
> Rajini
>
> On Tue, Oct 31, 2017 at 9:58
+1 (binding)
Thanks for the KIP, Jorge.
Regards,
Rajini
On Tue, Oct 31, 2017 at 9:58 AM, Damian Guy wrote:
> Thanks for the KIP - +1 (binding)
>
> On Mon, 23 Oct 2017 at 18:39 Guozhang Wang wrote:
>
> > Thanks Jorge for driving this KIP! +1
Thanks for the KIP - +1 (binding)
On Mon, 23 Oct 2017 at 18:39 Guozhang Wang wrote:
> Thanks Jorge for driving this KIP! +1 (binding).
>
>
> Guozhang
>
> On Mon, Oct 16, 2017 at 2:11 PM, Bill Bejeck wrote:
>
> > +1
> >
> > Thanks,
> > Bill
> >
> > On Fri,
Thanks Jorge for driving this KIP! +1 (binding).
Guozhang
On Mon, Oct 16, 2017 at 2:11 PM, Bill Bejeck wrote:
> +1
>
> Thanks,
> Bill
>
> On Fri, Oct 13, 2017 at 6:36 PM, Ted Yu wrote:
>
> > +1
> >
> > On Fri, Oct 13, 2017 at 3:32 PM, Matthias J. Sax
+1
Thanks,
Bill
On Fri, Oct 13, 2017 at 6:36 PM, Ted Yu wrote:
> +1
>
> On Fri, Oct 13, 2017 at 3:32 PM, Matthias J. Sax
> wrote:
>
> > +1
> >
> >
> >
> > On 9/11/17 3:04 PM, Jorge Esteban Quilcate Otoya wrote:
> > > Hi All,
> > >
> > > It seems
+1
On Fri, Oct 13, 2017 at 3:32 PM, Matthias J. Sax
wrote:
> +1
>
>
>
> On 9/11/17 3:04 PM, Jorge Esteban Quilcate Otoya wrote:
> > Hi All,
> >
> > It seems that there is no further concern with the KIP-171.
> > At this point we would like to start the voting process.
> >
+1
On 9/11/17 3:04 PM, Jorge Esteban Quilcate Otoya wrote:
> Hi All,
>
> It seems that there is no further concern with the KIP-171.
> At this point we would like to start the voting process.
>
> The KIP can be found here:
>
Thanks for the KIP Jorge, overall it looks good.
As Matthias mentioned in the DISCUSS thread, while working on KIP-198 we
realize that the o.a.k.admin.AdminClient does not yet have all the
functionalities that k.a.AdminClient (in Scala) have, for example,
describeConsumerGroup().
Thus, could you
21 matches
Mail list logo