On Tue, May 3, 2022, at 20:48, Israel Ekpo wrote: > Hi Colin, > > Thanks for this KIP. I am very excited to see the proposal. > > A lot in the community have been asking when KRaft mode will be ready and I > think this KIP will provide a lot of the answers and guidance desperately > needed. > > Thanks for working on it. > > I also have some of the questions from Luke regarding the duration of the > deprecation period and the release where ZK will be completely dropped. > > As per our time-based release plan [1], the release should be every 4 > months, but it has been approximately 5 months between releases from the > downloads page [2] > > So, right now we are about to push out 3.2.0 and 3.4.0 is approximately 10 > months from now based on the schedule/plan. >
Hi Israel, Sorry, I meant to write "the next release, 3.3" not "the next release, 3.4." I fixed the KIP text now. As you noted, 3.3 should be about 4 or 5 months from now. > I wonder if this will be enough time to complete all the features needed to > bring KRaft mode to parity with Legacy/Zookeeper mode. > > The missing features you have highlighted and any other critical features > not working in KRaft mode should be implemented fully before marking KRaft > mode as production ready and deprecating Legacy mode. > As I wrote in "potential objections and responses," I don't think we need full feature parity before marking KRaft mode as production ready. It's customary for Kafka to bring new features to production incrementally. > > The main question here is would we have Kafka versions 3.6.0, 3.7.0, 3.8.0 > and 3.9.0 because this will add approximately 20 additional months after > 3.4.0 which should be enough time to have ZK-mode deprecated and tested > thoroughly before removal completely. I feel we should not mark ZK mode as > deprecated until all the features in KRaft mode are at parity with ZK-mode. > > If we are going to have 20 months after 3.4 to work with a deprecated > ZK-mode, then it could be possible to even drop ZK fully before 4.0 > > Let's move the boat closer to the dock before we jump out of the boat. It > will be very stressful if we jump out of the boat and have to swim several > miles to shore. > That is a lot of Kafka versions! I don't think anyone wants 3.x to go on that long, or the ZooKeeper metadata implementation either. Ultimately I believe such a very long multi-year transition period would make the code quality and project stability worse, since we'd have to split our efforts across the two implementations. To be clear, the proposal here is to have the bridge release be 3.4 and then move on to a ZK-free 4.0. With a 3.5 release as an option (but not requirement) if we can't finish everything in time after 3.4. So that would be two more releases with ZK, or dropping ZK a little bit less than a year from now. best, Colin > > [1] > https://cwiki.apache.org/confluence/display/KAFKA/Time+Based+Release+Plan > [2] https://kafka.apache.org/downloads > > > Israel Ekpo > Lead Instructor, IzzyAcademy.com > https://www.youtube.com/c/izzyacademy > https://izzyacademy.com/ > > > On Tue, May 3, 2022 at 10:32 PM Luke Chen <show...@gmail.com> wrote: > >> Hi Colin, >> >> So exciting to see the KIP to mark the Kraft production ready! >> >> Just one comment: We should make sure the period between ZK deprecation >> (i.e. v3.4.0) to ZK removal (i.e. v4.0.0) is not too short. >> Do we have any expectation for the deprecation period? >> After all, this is not a small feature change, and users need more time to >> do the migration. >> But to be honest, I don't know how long is long enough. >> Maybe at least half a year? Or more? Thoughts? >> >> >> Thank you. >> Luke >> >> On Wed, May 4, 2022 at 9:10 AM Colin McCabe <cmcc...@apache.org> wrote: >> >> > Hi all, >> > >> > I've written a KIP for marking KRaft as production ready. Please take a >> > look if you have a chance: >> > >> > https://cwiki.apache.org/confluence/x/8xKhD >> > >> > thanks, >> > Colin >> > >>
