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 <ning2008w...@gmail.com> wrote: > 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 path: > assuming KIP-712 should have been battle-tested in the real-world industry > for years, I guess it may not take a long time to get KIP-712 in together > with an explicit statement that KIP-712 can be applied to MM2. After that, > port KIP-712 to MM2 immediately, followed up with executing KIP-720 and a > migration SOP from MM1 to MM2. > > happy to hear other thoughts. > > On 2021/03/26 17:45:06, Tom Bentley <tbent...@redhat.com> wrote: > > 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 everything that MM1 does. We could > end > > up giving people a perverse incentive to stick with, or even adopt, MM1. > > Doing both these KIPs would be a confusing thing to try to communicate to > > users. > > > > Tom > > > > On Fri, Mar 26, 2021 at 5:12 PM Ryanne Dolan <ryannedo...@gmail.com> > wrote: > > > > > 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 said, I know that many orgs use MM1 and will probably > > > continue to do so for a while, and some may never switch. I don't think > > > that's an argument for keeping MM1 around upstream long-term, and I > don't > > > think anyone is making that argument, so far. I guess I could remove > the > > > phrase "MM1 remains useful" but I specifically wanted to leave room for > > > KIP-712, which cites MM1 as motivation. (There are definitely plans to > > > bring the goodness of KIP-712 to MM2, assuming it passes, and I don't > want > > > KIP-720 to jeopardize that.) > > > > > > Ryanne > > > > > > On Fri, Mar 26, 2021, 11:20 AM Tom Bentley <tbent...@redhat.com> > wrote: > > > > > > > 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 > > > > might be, depending on the details. It isn't completely clear to me > > > whether > > > > you're asserting that MM2 covers all the same use cases as MM1. On > the > > > one > > > > hand you don't want to make claims, but on the other you're saying we > > > have > > > > MM2 now. An assertion that MM2 addressed all the MM1 use cases would > be > > > > Ismael's explanation about why MM1 is no longer useful, I think. > OTOH the > > > > KIP says it is still useful. So personally I'm confused about which > the > > > > situation is. > > > > > > > > Are we deprecating something which for some users MM2 cannot > replace? If > > > > so, I think the KIP should explain clearly why we're intentionally > doing > > > > that. > > > > > > > > Kind regards, > > > > > > > > Tom > > > > > > > > On Fri, Mar 26, 2021 at 3:22 PM Ryanne Dolan <ryannedo...@gmail.com> > > > > wrote: > > > > > > > > > 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 > > > > say, > > > > > IMO. > > > > > > > > > > Ryanne > > > > > > > > > > On Mon, Mar 22, 2021 at 8:04 AM Ismael Juma <ism...@juma.me.uk> > wrote: > > > > > > > > > > > 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. > > > > > > > > > > > > Thanks, > > > > > > Ismael > > > > > > > > > > > > On Sat, Mar 20, 2021 at 10:41 AM Ryanne Dolan < > ryannedo...@gmail.com > > > > > > > > > > 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 > > > > > > > > > > > > > > Thanks! > > > > > > > Ryanne > > > > > > > > > > > > > > > > > > > > > > > > > > > >
