Hi all, Thanks for the feedback. A few thoughts follow.
The ideal scenario would be for us to provide a tool for no downtime migration as discussed in the original thread (I filed https://issues.apache.org/jira/browse/KAFKA-4513 in response to that discussion). There are a few issues, however: - There doesn't seem to be much demand for it (outside of LinkedIn, at least) - No-one is working on it or has indicated that they are planning to work on it - It's a non-trivial change and it requires a good amount of testing to ensure it works as expected I suggested the KIP to raise awareness. Maybe there's more demand than we think and/or someone is planning to work on it. The latter, in particular, would be great news. In the meantime, we have this suboptimal situation where the old consumers are close to unmaintained even though we don't say it outright: they don't get new features (basic things like security are missing) and bug fixes are rare. In practice, the old clients have been deprecated a while back, we just haven't made it official. This proposal is about rectifying that so that we communicate our intentions to our users more clearly. As Vahid said, this KIP is not about changing how we maintain the existing code. The KIP that proposes the removal of all the old clients will be more interesting, but it doesn't exist yet. :) Ismael On Fri, Jan 6, 2017 at 3:27 AM, Vahid S Hashemian <vahidhashem...@us.ibm.com > wrote: > One thing that probably needs some clarification is what is implied by > "deprecated" in the Kafka project. > I googled it a bit and it doesn't seem that deprecation conventionally > implies termination of support (or anything that could negatively impact > existing users). That's my interpretation too. > It would be good to know if Kafka follows a different interpretation of > the term. > > If my understanding of the term is correct, since we are not yet targeting > a certain major release in which the old consumer will be removed, I don't > see any harm in marking it as deprecated. > There will be enough time to plan and implement the migration, if the > community decides that's the way to go, before phasing it out. > > At the minimum new Kafka users will pick the Java consumer without any > confusion. And existing users will know that Kafka is preparing for the > old consumer's retirement. > > --Vahid > > > > > From: Joel Koshy <jjkosh...@gmail.com> > To: "dev@kafka.apache.org" <dev@kafka.apache.org> > Date: 01/05/2017 06:55 PM > Subject: Re: [DISCUSS] KIP-109: Old Consumer Deprecation > > > > While I realize this only marks the old consumer as deprecated and not a > complete removal, I agree that it is somewhat premature to do this prior > to > having a migration process implemented. Onur has described this in detail > in the earlier thread: http://markmail.org/message/ekv352zy7xttco5s and > I'm > surprised that more companies aren't affected by (or aware of?) the issue. > > On Thu, Jan 5, 2017 at 4:40 PM, radai <radai.rosenbl...@gmail.com> wrote: > > > I cant speak for anyone else, but a rolling upgrade is definitely how we > > (LinkedIn) will do the migration. > > > > On Thu, Jan 5, 2017 at 4:28 PM, Gwen Shapira <g...@confluent.io> wrote: > > > > > it sounds good to have > > > it, but that's probably not how people will end up migrati > > > > > > > > > >
