On Mon, May 4, 2020, at 17:33, Gwen Shapira wrote: > +1 for removing MM 1.0 when we cut a breaking release. It is sad to see > that we are still investing in it (I just saw a KIP toward improving its > reset policy). > > My understanding was that KIP-590 is not breaking compatibility, I think > Guozhang said that in response to my question on the discussion thread.
Hi Gwen, The latest proposal for KIP-590 does break compatibility because it requires principals to be serializable. So anyone implementing custom KafkaPrincipal subclasses would have to add support for such serialization. > > Overall, since Kafka has time-based releases, we can make the call on 3.0 > vs 2.7 when we are at "KIP freeze date" and can see which features are > likely to make it. > The release we're discussing won't happen until October or November, so I would put this more in the category of mid or long-term planning rather than short term planning. It would be good to get some clarity on what we're going to do here. If we can't drop support for the --zookeeper flags in November then I think the KIP-500 work will be delayed. Remember that there are a lot of downstream users who won't migrate off of the --zookeeper flags until they're really gone-- things like k8s integrations, puppet, chef, and ansible integrations, and so on. best, Colin > > > On Mon, May 4, 2020 at 5:13 PM Ryanne Dolan <ryannedo...@gmail.com> wrote: > > > Hey Colin, I think we should wait until after KIP-500's "bridge release" so > > there is a clean break from Zookeeper after 3.0. The bridge release by > > definition is an attempt to not break anything, so it theoretically doesn't > > warrant a major release. If that's not the case (i.e. if a single "bridge > > release" turns out to be impractical), we should consider forking 3.0 while > > maintaining a line of Zookeeper-dependent Kafka in 2.x. That way 3.x can > > evolve dramatically without breaking the 2.x line. In particular, anything > > related to removing Zookeeper could land in pre-3.0 while every other > > feature targets 2.6. > > > > If you are proposing 2.6 should be the "bridge release", I think this is > > premature given Kafka's time-based release schedule. If the bridge features > > happen to be merged before 2.6's feature freeze, then sure -- let's make > > that the bridge release in retrospect. And if we get all the post-Zookeeper > > features merged before 2.7, I'm onboard with naming it "3.0" instead. > > > > That said, we should aim to remove legacy MirrorMaker before 3.0 as well. > > I'm happy to drive that additional breaking change. Maybe 2.6 can be the > > "bridge" for MM2 as well. > > > > Ryanne > > > > On Mon, May 4, 2020, 5:05 PM Colin McCabe <cmcc...@apache.org> wrote: > > > > > Hi all, > > > > > > We've had a few proposals recently for incompatible changes. One of them > > > is my KIP-604: Remove ZooKeeper Flags from the Administrative Tools. The > > > other is Boyang's KIP-590: Redirect ZK Mutation Protocols to the > > > Controller. I think it's time to start thinking about Kafka 3.0. > > > Specifically, I think we should move to 3.0 after the 2.6 release. > > > > > > From the perspective of KIP-500, in Kafka 3.x we'd like to make running > > in > > > a ZooKeeper-less mode possible (but not yet the default.) This is the > > > motivation behind KIP-590 and KIP-604, as well as some of the other KIPs > > > we've done recently. Since it will take some time to stabilize the new > > > ZooKeeper-free Kafka code, we will hide it behind an option initially. > > > (We'll have a KIP describing this all in detail soon.) > > > > > > What does everyone think about having Kafka 3.0 come up next after 2.6? > > > Are there any other things we should change in the 2.6 -> 3.0 transition? > > > > > > best, > > > Colin > > > > > > > > -- > Gwen Shapira > Engineering Manager | Confluent > 650.450.2760 | @gwenshap > Follow us: Twitter | blog >
