You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Ewen Cheslack-Postava <ew...@confluent.io> on 2017/05/03 06:05:27 UTC
Re: [DISCUSS] KIP-137: Enhance TopicCommand --describe to show topics
marked for deletion
Since everything is whitespace delimited anyway, I don't think we should
worry about the compatibility issue. We don't guarantee this unstructured
output format. I think it is fine to say that any parser that doesn't do
something straightforward and reliable like splitting the line by
whitespace then checking the : prefixed value to determine if it is usable
is ok to break.
Long term, we should really just get more structured output formats for the
command line tools, a la https://issues.apache.org/jira/browse/KAFKA-313.
-Ewen
On Wed, Apr 26, 2017 at 2:59 AM, Ismael Juma <is...@juma.me.uk> wrote:
> Right, the reason for inserting it before the configs is that
> MarkedForDeletion is a fixed length field while configs is a variable
> length field. The fact that MarkedForDeletion is optional and typically not
> set means that it's also justifiable to place it after the configs. So, I'm
> OK either way.
>
> Ismael
>
> On Wed, Apr 26, 2017 at 10:42 AM, Mickael Maison <mickael.maison@gmail.com
> >
> wrote:
>
> > Thanks for the feedback.
> >
> > I had the same thinking as James. Also we plan to only add the
> > MarkedForDeletion field for topics pending deletion as the output of
> > --describe is already pretty dense and most topics are never pending
> > deletion.
> >
> > The only reason I came up to insert it in the middle is if Configs is
> > long, then MarkedForDeletion could be pushed on a new line/off-screen.
> > Am I missing something ?
> >
> > That said, I don't have a strong opinion about it and if most people
> > prefer it the other way around I'll be happy to update the KIP.
> >
> > On Wed, Apr 26, 2017 at 12:25 AM, James Cheng <wu...@gmail.com>
> > wrote:
> > > Having "MarkedForDeletion" before "Configs" may break anyone who is
> > parsing this output, since they may be expecting the 4th string to be
> > "Configs".
> > >
> > > I know that the Compatibility section already says that people parsing
> > this may have to adjust their parsing logic, so maybe that covers my
> > concern already. But inserting the new MarkedForDeletion word into the
> > middle of the string seems like it'll break parsing more than just
> adding a
> > new value at the end.
> > >
> > > I'm fine either way, though.
> > >
> > > -James
> > >
> > >> On Apr 25, 2017, at 9:38 AM, Vahid S Hashemian <
> > vahidhashemian@us.ibm.com> wrote:
> > >>
> > >> Thanks for the KIP Mickael.
> > >> Looks good. I also prefer 'MarkedForDeletion' before 'Configs'.
> > >>
> > >> --Vahid
> > >>
> > >>
> > >>
> > >> From: Ismael Juma <is...@juma.me.uk>
> > >> To: dev@kafka.apache.org
> > >> Date: 04/25/2017 04:15 AM
> > >> Subject: Re: [DISCUSS] KIP-137: Enhance TopicCommand --describe
> > to
> > >> show topics marked for deletion
> > >> Sent by: ismaelj@gmail.com
> > >>
> > >>
> > >>
> > >> Thanks for the KIP. Would it make sense for MarkedForDeletion to be
> > before
> > >> `Configs`? I can see arguments both ways, so I was wondering what your
> > >> thoughts were?
> > >>
> > >> Ismael
> > >>
> > >> On Thu, Mar 30, 2017 at 5:39 PM, Mickael Maison <
> > mickael.maison@gmail.com>
> > >> wrote:
> > >>
> > >>> Hi all,
> > >>>
> > >>> We created KIP-137: Enhance TopicCommand --describe to show topics
> > >>> marked for deletion
> > >>>
> > >>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > >>>
> > >> 137%3A+Enhance+TopicCommand+--describe+to+show+topics+marked
> > +for+deletion
> > >>>
> > >>> Please help review the KIP. You feedback is appreciated!
> > >>>
> > >>> Thanks
> > >>>
> > >>
> > >>
> > >>
> > >>
> > >
> >
>
Re: [DISCUSS] KIP-137: Enhance TopicCommand --describe to show topics
marked for deletion
Posted by Mickael Maison <mi...@gmail.com>.
Yes it's what I was thinking when writing this up, JSON output would
be nice. I'll be happy to have a look at it. I'm guessing that would
require another KIP ?
On Wed, May 3, 2017 at 8:26 AM, Ismael Juma <is...@juma.me.uk> wrote:
> Yeah, structured output for the CLI tools would be great. 3 digit number
> JIRA, nice. :)
>
> Ismael
>
> On Wed, May 3, 2017 at 7:05 AM, Ewen Cheslack-Postava <ew...@confluent.io>
> wrote:
>
>> Since everything is whitespace delimited anyway, I don't think we should
>> worry about the compatibility issue. We don't guarantee this unstructured
>> output format. I think it is fine to say that any parser that doesn't do
>> something straightforward and reliable like splitting the line by
>> whitespace then checking the : prefixed value to determine if it is usable
>> is ok to break.
>>
>> Long term, we should really just get more structured output formats for the
>> command line tools, a la https://issues.apache.org/jira/browse/KAFKA-313.
>>
>> -Ewen
>>
>> On Wed, Apr 26, 2017 at 2:59 AM, Ismael Juma <is...@juma.me.uk> wrote:
>>
>> > Right, the reason for inserting it before the configs is that
>> > MarkedForDeletion is a fixed length field while configs is a variable
>> > length field. The fact that MarkedForDeletion is optional and typically
>> not
>> > set means that it's also justifiable to place it after the configs. So,
>> I'm
>> > OK either way.
>> >
>> > Ismael
>> >
>> > On Wed, Apr 26, 2017 at 10:42 AM, Mickael Maison <
>> mickael.maison@gmail.com
>> > >
>> > wrote:
>> >
>> > > Thanks for the feedback.
>> > >
>> > > I had the same thinking as James. Also we plan to only add the
>> > > MarkedForDeletion field for topics pending deletion as the output of
>> > > --describe is already pretty dense and most topics are never pending
>> > > deletion.
>> > >
>> > > The only reason I came up to insert it in the middle is if Configs is
>> > > long, then MarkedForDeletion could be pushed on a new line/off-screen.
>> > > Am I missing something ?
>> > >
>> > > That said, I don't have a strong opinion about it and if most people
>> > > prefer it the other way around I'll be happy to update the KIP.
>> > >
>> > > On Wed, Apr 26, 2017 at 12:25 AM, James Cheng <wu...@gmail.com>
>> > > wrote:
>> > > > Having "MarkedForDeletion" before "Configs" may break anyone who is
>> > > parsing this output, since they may be expecting the 4th string to be
>> > > "Configs".
>> > > >
>> > > > I know that the Compatibility section already says that people
>> parsing
>> > > this may have to adjust their parsing logic, so maybe that covers my
>> > > concern already. But inserting the new MarkedForDeletion word into the
>> > > middle of the string seems like it'll break parsing more than just
>> > adding a
>> > > new value at the end.
>> > > >
>> > > > I'm fine either way, though.
>> > > >
>> > > > -James
>> > > >
>> > > >> On Apr 25, 2017, at 9:38 AM, Vahid S Hashemian <
>> > > vahidhashemian@us.ibm.com> wrote:
>> > > >>
>> > > >> Thanks for the KIP Mickael.
>> > > >> Looks good. I also prefer 'MarkedForDeletion' before 'Configs'.
>> > > >>
>> > > >> --Vahid
>> > > >>
>> > > >>
>> > > >>
>> > > >> From: Ismael Juma <is...@juma.me.uk>
>> > > >> To: dev@kafka.apache.org
>> > > >> Date: 04/25/2017 04:15 AM
>> > > >> Subject: Re: [DISCUSS] KIP-137: Enhance TopicCommand
>> --describe
>> > > to
>> > > >> show topics marked for deletion
>> > > >> Sent by: ismaelj@gmail.com
>> > > >>
>> > > >>
>> > > >>
>> > > >> Thanks for the KIP. Would it make sense for MarkedForDeletion to be
>> > > before
>> > > >> `Configs`? I can see arguments both ways, so I was wondering what
>> your
>> > > >> thoughts were?
>> > > >>
>> > > >> Ismael
>> > > >>
>> > > >> On Thu, Mar 30, 2017 at 5:39 PM, Mickael Maison <
>> > > mickael.maison@gmail.com>
>> > > >> wrote:
>> > > >>
>> > > >>> Hi all,
>> > > >>>
>> > > >>> We created KIP-137: Enhance TopicCommand --describe to show topics
>> > > >>> marked for deletion
>> > > >>>
>> > > >>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
>> > > >>>
>> > > >> 137%3A+Enhance+TopicCommand+--describe+to+show+topics+marked
>> > > +for+deletion
>> > > >>>
>> > > >>> Please help review the KIP. You feedback is appreciated!
>> > > >>>
>> > > >>> Thanks
>> > > >>>
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >
>> > >
>> >
>>
Re: [DISCUSS] KIP-137: Enhance TopicCommand --describe to show topics
marked for deletion
Posted by Ismael Juma <is...@juma.me.uk>.
Yeah, structured output for the CLI tools would be great. 3 digit number
JIRA, nice. :)
Ismael
On Wed, May 3, 2017 at 7:05 AM, Ewen Cheslack-Postava <ew...@confluent.io>
wrote:
> Since everything is whitespace delimited anyway, I don't think we should
> worry about the compatibility issue. We don't guarantee this unstructured
> output format. I think it is fine to say that any parser that doesn't do
> something straightforward and reliable like splitting the line by
> whitespace then checking the : prefixed value to determine if it is usable
> is ok to break.
>
> Long term, we should really just get more structured output formats for the
> command line tools, a la https://issues.apache.org/jira/browse/KAFKA-313.
>
> -Ewen
>
> On Wed, Apr 26, 2017 at 2:59 AM, Ismael Juma <is...@juma.me.uk> wrote:
>
> > Right, the reason for inserting it before the configs is that
> > MarkedForDeletion is a fixed length field while configs is a variable
> > length field. The fact that MarkedForDeletion is optional and typically
> not
> > set means that it's also justifiable to place it after the configs. So,
> I'm
> > OK either way.
> >
> > Ismael
> >
> > On Wed, Apr 26, 2017 at 10:42 AM, Mickael Maison <
> mickael.maison@gmail.com
> > >
> > wrote:
> >
> > > Thanks for the feedback.
> > >
> > > I had the same thinking as James. Also we plan to only add the
> > > MarkedForDeletion field for topics pending deletion as the output of
> > > --describe is already pretty dense and most topics are never pending
> > > deletion.
> > >
> > > The only reason I came up to insert it in the middle is if Configs is
> > > long, then MarkedForDeletion could be pushed on a new line/off-screen.
> > > Am I missing something ?
> > >
> > > That said, I don't have a strong opinion about it and if most people
> > > prefer it the other way around I'll be happy to update the KIP.
> > >
> > > On Wed, Apr 26, 2017 at 12:25 AM, James Cheng <wu...@gmail.com>
> > > wrote:
> > > > Having "MarkedForDeletion" before "Configs" may break anyone who is
> > > parsing this output, since they may be expecting the 4th string to be
> > > "Configs".
> > > >
> > > > I know that the Compatibility section already says that people
> parsing
> > > this may have to adjust their parsing logic, so maybe that covers my
> > > concern already. But inserting the new MarkedForDeletion word into the
> > > middle of the string seems like it'll break parsing more than just
> > adding a
> > > new value at the end.
> > > >
> > > > I'm fine either way, though.
> > > >
> > > > -James
> > > >
> > > >> On Apr 25, 2017, at 9:38 AM, Vahid S Hashemian <
> > > vahidhashemian@us.ibm.com> wrote:
> > > >>
> > > >> Thanks for the KIP Mickael.
> > > >> Looks good. I also prefer 'MarkedForDeletion' before 'Configs'.
> > > >>
> > > >> --Vahid
> > > >>
> > > >>
> > > >>
> > > >> From: Ismael Juma <is...@juma.me.uk>
> > > >> To: dev@kafka.apache.org
> > > >> Date: 04/25/2017 04:15 AM
> > > >> Subject: Re: [DISCUSS] KIP-137: Enhance TopicCommand
> --describe
> > > to
> > > >> show topics marked for deletion
> > > >> Sent by: ismaelj@gmail.com
> > > >>
> > > >>
> > > >>
> > > >> Thanks for the KIP. Would it make sense for MarkedForDeletion to be
> > > before
> > > >> `Configs`? I can see arguments both ways, so I was wondering what
> your
> > > >> thoughts were?
> > > >>
> > > >> Ismael
> > > >>
> > > >> On Thu, Mar 30, 2017 at 5:39 PM, Mickael Maison <
> > > mickael.maison@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> Hi all,
> > > >>>
> > > >>> We created KIP-137: Enhance TopicCommand --describe to show topics
> > > >>> marked for deletion
> > > >>>
> > > >>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > >>>
> > > >> 137%3A+Enhance+TopicCommand+--describe+to+show+topics+marked
> > > +for+deletion
> > > >>>
> > > >>> Please help review the KIP. You feedback is appreciated!
> > > >>>
> > > >>> Thanks
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > >
> >
>