Sounds good, thank you! Moreover, I do feel it would be great to integrate
some of the motivation stuff into the option description, but we could
discuss more in the PR.
On Sat, Jul 18, 2020 at 3:24 AM Joel Wee wrote:
> I agree Boyang, we should be able to specify both `—internal-topics` and
> `
I agree Boyang, we should be able to specify both `—internal-topics` and
`—dry-run` at the same time and this should display the topics that will be
deleted. What I was trying to communicate in the description is that if you
want to see all the topics that are valid as input into the option, the
Thanks for the update!
On Fri, Jul 3, 2020 at 3:18 PM Joel Wee wrote:
> Thanks all for voting!
>
> I am closing the vote as accepted with three binding +1 votes (Boyang,
> Guozhang, John).
>
> Thanks John for the suggestion. I think that makes sense. I have updated
> the KIP to say that only top
Thanks all for voting!
I am closing the vote as accepted with three binding +1 votes (Boyang,
Guozhang, John).
Thanks John for the suggestion. I think that makes sense. I have updated the
KIP to say that only topics flagged as internal by the tool can be deleted, and
have also rephrased the o
Hey Bruno,
I agree adding a prompt would be a nice precaution, but it is not backward
compatible as you suggested and could make the automation harder to
achieve.
If you want, we may consider starting a separate ticket to discuss whether
adding a prompt to let users be aware of the topics that ar
Hi,
I have already brought this up in the discussion thread.
Should we not run a dry-run in any case to avoid inadvertently
deleting topics of other applications?
I know it is a backward incompatible change if users use it in
scripts, but I think it is still worth discussing it. I would to hear
Thanks John for the great suggestion. +1 for enforcing the prefix check for
the `--internal-topics` list.
On Mon, Jun 29, 2020 at 5:11 PM John Roesler wrote:
> Oh, I meant to say, if that’s the case, then I’m +1 (binding) also :)
>
> Thanks again,
> John
>
> On Mon, Jun 29, 2020, at 19:09, John
Oh, I meant to say, if that’s the case, then I’m +1 (binding) also :)
Thanks again,
John
On Mon, Jun 29, 2020, at 19:09, John Roesler wrote:
> Thanks for the KIP, Joel!
>
> It seems like a good pattern to document would be to first run with
> —dry-run and without —internal-topics to list all po
Thanks for the KIP, Joel!
It seems like a good pattern to document would be to first run with —dry-run
and without —internal-topics to list all potential topics, and then to use
—internal-topics if needed to limit the internal topics to delete.
Just to make sure, would we have a sanity check t
Thanks Joel, the KIP lgtm.
A minor suggestion is to explain where users can get the list of internal
topics of a given application, and maybe also add it as part of the helper
scripts, for example via topology description.
Overall, I'm +1 as well (binding).
Guozhang
On Sat, Jun 27, 2020 at 4:3
Thanks Boyang, I think what you’ve said makes sense. I’ve made the motivation
clearer now:
Users may want to specify which internal topics should be deleted. At present,
the streams reset tool deletes all topics that start with
"http://application.id>>-" and there are no options to control
it
Thanks for driving the proposal Joel, I have a minor suggestion: we should
be more clear about why we introduce this flag, so it would be better to
also state clearly in the document for the default behavior as well, such
like:
Comma-separated list of internal topics to be deleted. By default,
St
Apologies. Changing the subject.
On 24 Jun 2020, at 9:14 PM, Joel Wee
mailto:joel@outlook.com>> wrote:
Hi all
I would like to start a vote for KIP-623, which adds the option
--internal-topics to the streams-application-reset-tool:
https://cwiki.apache.org/confluence/pages/viewpage.action?
13 matches
Mail list logo
