Thanks, Ryanne. Can you add information about this way forward to the KIP? Also
it would be good to clarify that this work needs to get done before removing
MM1.
best,
Colin
On Thu, May 20, 2021, at 16:00, Ryanne Dolan wrote:
> Hey y'all, reviving this thread because it seems we have a way for
Hey y'all, reviving this thread because it seems we have a way forward
w.r.t. IdentityReplicationPolicy aka LegacyReplicationPolicy, which I
believe is the only missing feature in MM2 that we need to deprecate MM1.
If there are no objections over the next couple of days I'll consider this
adopted.
Hi Ryanne,
Thanks for the response. It would be good to have a PR for KIP-382, I agree.
Perhaps one possible compromise for KIP-712 would be to make the changes in MM2
first, and then backport them to MM1. I think it's important that when we have
a deprecated way of doing something and a non-
Thank you Ryanne. It's hopefully obvious, but I meant MirrorMaker 1 in the
following:
"we propose deprecating MirrorMaker 2 for future removal."
On Thu, Apr 1, 2021 at 3:50 PM Ryanne Dolan wrote:
> Ismael, that certainly works for me. I'll update the KIP. Thanks for
> raising the issue.
>
> Rya
Ismael, that certainly works for me. I'll update the KIP. Thanks for
raising the issue.
Ryanne
On Thu, Apr 1, 2021, 11:45 AM Ismael Juma wrote:
> OK. :) Maybe something like:
>
> "We believe MirrorMaker 2 is an improvement over the original MirrorMaker
> when it comes to reliability and functi
Colin, the only feature gap I'm aware of is that users must provide their
own ReplicationPolicy in order to replicate topics without renaming them.
This is straightforward, and such ReplicationPolicy implementations are
easy to find. We could provide one OOTB, and indeed KIP-382 proposes we do
so,
Thanks for bringing this up, Ismael. I agree that we need to figure this out
before we accept this KIP.
If MM1 is deprecated, then that means we are telling users they need to migrate
away from it as soon as they can. I think that rules out adding big new
features to MM1, unless those feature
OK. :) Maybe something like:
"We believe MirrorMaker 2 is an improvement over the original MirrorMaker
when it comes to reliability and functionality for the majority of use
cases. We intend to focus on MirrorMaker 2 for future development and hence
we propose deprecating MirrorMaker 2 for future
Ah, do you mind wording it for me, Ismael? Or do you mean I should just
remove the "MM1 is still useful" part?
Ryanne
On Thu, Apr 1, 2021, 11:01 AM Ismael Juma wrote:
> Can we please add proper motivation? I'm -1 with the current motivation
> even though I'm in favor of the change.
>
> On Thu,
Can we please add proper motivation? I'm -1 with the current motivation
even though I'm in favor of the change.
On Thu, Apr 1, 2021, 8:46 AM Ryanne Dolan wrote:
> Hey y'all, looks like we've got the requisite votes for this to pass, and
> the various concerns wrt KIP-712 are now being discussed
Hey y'all, looks like we've got the requisite votes for this to pass, and
the various concerns wrt KIP-712 are now being discussed on that thread. So
I'm going to go ahead and close the vote here.
Thanks for the votes!
Ryanne
On Fri, Mar 26, 2021, 11:26 PM Ismael Juma wrote:
> It does mean mor
It does mean more than that. We don't remove or replace things in Apache
Kafka without good reasons (since it's typically costly for users). And
once something is scheduled for removal, it's typically in maintenance mode
and only bug fixes are expected.
Ismael
On Fri, Mar 26, 2021, 8:28 PM Ryanne
Ismael, "deprecated" implies something is scheduled to be removed or
replaced, but I don't think it implies anything more than that. KIP-720 is
proposing to deprecate MM1 so it can eventually be removed. That's all this
particular KIP is proposing.
Ryanne
On Fri, Mar 26, 2021, 7:24 PM Ismael Juma
Thanks Tom, this is a good elaboration on what I meant. Also, if it's
deprecated, then we should definitely not be adding features. I'm a puzzled
that we are saying that MM1 is useful, deserves additional development and
should be deprecated - all at the same time.
Ismael
On Fri, Mar 26, 2021, 9:
The timing is unfortunate, but should not be a roadblock. Both KIPs are
already worded to leave room for the other. I think this is a non-issue.
On Fri, Mar 26, 2021 at 2:49 PM Ning Zhang wrote:
> IMHO - I think there is no too much doubt on the effectiveness of KIP-712
> and KIP-720, the tricky
IMHO - I think there is no too much doubt on the effectiveness of KIP-712 and
KIP-720, the tricky part may be the timing and the ordering of implementing
KIP-712 and KIP-720 (if we do not want to execute both KIP in parallel).
If it makes more sense to execute them in sequence, here may be a pat
Hi Ryanne,
Thanks for the clarification. I agree that inertia is not a good enough
reason to keep MM1 around.
It is a bit weird to be deprecating MM1 in one KIP but proposing to develop
it further in another, and that development, if it happened, would
undermine the argument that MM2 does everyth
Tom, to clarify, MM2 can definitely replace MM1 in all use cases I've
encountered or can imagine, and many orgs have switched already, e.g. using
IdentityReplicationPolicy aka LegacyReplicationPolicy. Moreover, the
argument of whether to extend or replace MM1 was already decided in
KIP-382. That sa
Hi Ryanne,
With respect, there's a difference between "we still use it because we
can't be bothered to switch to MM2, or just haven't yet" and "it's
important for xyz because MM2 doesn't serve our use case properly". While
the former is not a good reason to argue against deprecation, the latter
mi
Ismael, I think it is very difficult in general to argue for deprecation --
someone will always say "we still use it" or "it's important for xyz" -- so
I don't want to make claims that prompt such responses. The motivation for
deprecating MM1 is that we now have MM2, and there isn't much else to sa
I am in favor of this change, but the KIP doesn't include proper
motivation. It says "While the original MirrorMaker remains useful, we want
to take advantage of the upcoming 3.0 major release to officially deprecate
this legacy code". I would hope we would explain why it's no longer useful
instead
+1 (binding)
Thanks Ryanne
On Mon, Mar 22, 2021 at 10:18 AM David Jacot
wrote:
>
> +1 (binding)
>
> Thanks for the KIP!
>
> On Mon, Mar 22, 2021 at 8:29 AM Manikumar wrote:
>
> > +1 (binding)
> >
> >
> >
> > On Mon, Mar 22, 2021 at 9:42 AM Gwen Shapira
> > wrote:
> >
> > > Woot!
> > > +1
> > >
+1 (binding)
Thanks for the KIP!
On Mon, Mar 22, 2021 at 8:29 AM Manikumar wrote:
> +1 (binding)
>
>
>
> On Mon, Mar 22, 2021 at 9:42 AM Gwen Shapira
> wrote:
>
> > Woot!
> > +1
> >
> > On Sat, Mar 20, 2021, 10:41 AM Ryanne Dolan
> wrote:
> >
> > > Hey y'all, I'm starting the vote on KIP-720,
+1 (binding)
On Mon, Mar 22, 2021 at 9:42 AM Gwen Shapira
wrote:
> Woot!
> +1
>
> On Sat, Mar 20, 2021, 10:41 AM Ryanne Dolan wrote:
>
> > Hey y'all, I'm starting the vote on KIP-720, which proposes to deprecate
> > the original MirrorMaker in the upcoming 3.0 major release.
> >
> >
> >
> htt
Woot!
+1
On Sat, Mar 20, 2021, 10:41 AM Ryanne Dolan wrote:
> Hey y'all, I'm starting the vote on KIP-720, which proposes to deprecate
> the original MirrorMaker in the upcoming 3.0 major release.
>
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-720%3A+Deprecate+MirrorMaker+v1
>
> Tha
Hey y'all, I'm starting the vote on KIP-720, which proposes to deprecate
the original MirrorMaker in the upcoming 3.0 major release.
https://cwiki.apache.org/confluence/display/KAFKA/KIP-720%3A+Deprecate+MirrorMaker+v1
Thanks!
Ryanne
26 matches
Mail list logo
