Thanks Colin for the update and clarification and the additional details
you added.

I second Igor's thoughts that we should not deprecate ZK before having
feature parity.

However, I think marking KRaft mode as production-ready is something that
can be done independent of the status of feature parity (between ZK-mode
and KRaft-mode).

Maybe we can mark KRaft as production ready for now (in 3.3) then work on
getting to feature parity in 3.4 and once feature parity is attained, then
we deprecate ZK-mode in 3.4 and remove it in the next release after 3.4.

That would be fair from my perspective.

It is a bit hard to ask users to jump off the boat when the dock is still
far away and they are unable to swim that far.

Some of the missing features are still in the critical path for some users
and we should include them in the project before the ZK-mode deprecation or
removal.

These are my initial thoughts about this and I believe users may not feel
supported if the cord is just ripped off with features still missing and
Zookeeper is gone.

That could send a wrong message to the community of current and prospective
users.

Israel Ekpo
Lead Instructor, IzzyAcademy.com
https://www.youtube.com/c/izzyacademy
https://izzyacademy.com/


On Wed, May 4, 2022 at 5:58 AM Igor Soarez <i...@soarez.me> wrote:

> Hi Colin,
>
> It's very exciting to see KRaft ready for production!
>
> I see the value of marking it ready for production even with the current
> missing features.
>
> However, I'm worried about marking ZK mode as deprecated before these
> missing features are ready. It might be hard to estimate right now how much
> work is actually necessary to close that gap, particularly the upgrade from
> ZK. Deprecating ZK before providing users with an upgrade path might be
> sending the wrong message - when something is deprecated we want users to
> move away from it, so that should be possible. It might well be more than a
> few months to close the gap.
>
> Best,
>
> --
> Igor
>
> On Wed, May 4, 2022, at 7:22 AM, Colin McCabe wrote:
> > On Tue, May 3, 2022, at 23:16, Colin McCabe wrote:
> >>
> >> 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.
> >>
> >
> > Sigh. This should read "To be clear, the proposal here is to have the
> > bridge release be 3.3 and then move on to a ZK-free 4.0. With a 3.4
> > release as an option (but not requirement) if we can't finish
> > everything in time after 3.3." So much for being clear, I guess :)
> >
> > cheers,
> > Colin
> >
> >
> >> 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
> >>>> >
> >>>>
>

Reply via email to