From dev-return-90687-archive-asf-public=cust-asf.ponee.io@kafka.apache.org Fri Jan 5 04:33:57 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id 06AEB180657 for ; Fri, 5 Jan 2018 04:33:57 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id EAE6A160C3A; Fri, 5 Jan 2018 03:33:56 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 16218160C2B for ; Fri, 5 Jan 2018 04:33:55 +0100 (CET) Received: (qmail 33713 invoked by uid 500); 5 Jan 2018 03:33:54 -0000 Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@kafka.apache.org Delivered-To: mailing list dev@kafka.apache.org Received: (qmail 32333 invoked by uid 99); 5 Jan 2018 03:33:53 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Jan 2018 03:33:53 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 4C2E81A0481 for ; Fri, 5 Jan 2018 03:33:53 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.979 X-Spam-Level: * X-Spam-Status: No, score=1.979 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=confluent-io.20150623.gappssmtp.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id Nte8QThp1I-Z for ; Fri, 5 Jan 2018 03:33:49 +0000 (UTC) Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id BBAD65F239 for ; Fri, 5 Jan 2018 03:33:48 +0000 (UTC) Received: by mail-lf0-f43.google.com with SMTP id o26so3818222lfc.10 for ; Thu, 04 Jan 2018 19:33:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=confluent-io.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r3M2JBBOZxrl5QjeFxUgu62RYIq/dtR3vv+uuMOltKs=; b=cak72WA6pSsTDVkQ3nlEnhK0Sk6eTsK/CdoeZOpC5ouP7UeaIpMMGLEfj63wGpafRM mEF1X+c++8SU4cD6upSSpmpscCk7VGP+fwHw92bA/lCpIaR2Nx/1WuSd2MQXz0ajDM/m GvZBLtiIr+BKu9TE8snXJX+txdLlGF9kkiGPGGGYxnwnLuJh2dJA6QvZRHOjq1iouvvy BoUd0y5IJ5SOjlKv01u1zie/VFblSbF5FhQcAFdeBdkYs5HNe1GNJ2RLwOO+dfWxlrOp X1x6Slji9HgD9jN/51DhD88lGFSvZFeDthjXJeymxxtx/F24wljUCPTeNFNB/sMSQ0JV Tkrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r3M2JBBOZxrl5QjeFxUgu62RYIq/dtR3vv+uuMOltKs=; b=GZSIKc4Hy40A9ny/YAKBGiI38TugnC+kjpV/6i0NBD4VEda5BOMWkUWaQWAdsUzruq waUqtPdwdZ3kfvbJ6jWqql2oMtCl5ncss8g6vVmjC/BoG4H3WoxO46tS9Ilt9thrk4PB 4jvsPCz2ArKWHElQw53Lyn9lWu6jpUk3noQtH/u8ICCWEbUla3b2ayaH455lDkp1qrlm 40xccHZoy+bl3nspkfdRraqGxHi1rno7SwQwgyS182Rx7up8kFyKqZmNg8CrqnGEVd/N RGMXhVLdtHeD03HZT3uxLAISs3DqBFfl4nq2qaWHvSkg8Z9764fPbo2HL5O5bxKNCw/x iQ3A== X-Gm-Message-State: AKwxyteRdBhbvZzvZtQWzjrU13VN1uGdSFnEWsuNyYhZn4g5Sz7fp7hV P5TZ1jR0u3cmpImEXBoaUtRCGeptjvY//uOMaN/TCA== X-Google-Smtp-Source: ACJfBovgkOfWOgMRJywvfuFbwo2/U2fCHEw27hhh0kGWSpMO7VKcLrssL99VXy8r+tQjrph8bqSQI8b9Zzx6yhjwqdU= X-Received: by 10.25.89.82 with SMTP id n79mr647645lfb.133.1515123228168; Thu, 04 Jan 2018 19:33:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.56.87 with HTTP; Thu, 4 Jan 2018 19:33:47 -0800 (PST) In-Reply-To: References: From: Ewen Cheslack-Postava Date: Thu, 4 Jan 2018 19:33:47 -0800 Message-ID: Subject: Re: [DISCUSS] KIP-174 - Deprecate and remove internal converter configs in WorkerConfig To: UMESH CHAUDHARY Cc: dev@kafka.apache.org, "users@kafka.apache.org" Content-Type: multipart/alternative; boundary="001a11412adace6e200561ff1d1d" --001a11412adace6e200561ff1d1d Content-Type: text/plain; charset="UTF-8" Sorry I lost track of this thread. If things are in good shape we should probably vote on this and get the deprecation commit through. It seems like a good idea as this has been confusing to users from day one. -Ewen On Wed, Aug 9, 2017 at 5:18 AM, UMESH CHAUDHARY wrote: > Thanks Ewen, > I just edited the KIP to reflect the changes. > > Regards, > Umesh > > On Wed, 9 Aug 2017 at 11:00 Ewen Cheslack-Postava > wrote: > >> Great, looking good. I'd probably be a bit more concrete about the >> Proposed Changes (e.g., "will log an warning if the config is specified" >> and "since the JsonConverter is the default, the configs will be removed >> immediately from the example worker configuration files"). >> >> Other than that this LGTM and I'll be happy to get rid of those settings! >> >> -Ewen >> >> On Tue, Aug 8, 2017 at 2:54 AM, UMESH CHAUDHARY >> wrote: >> >>> Hi Ewen, >>> Sorry, I am bit late in responding this. >>> >>> Thanks for your inputs and I've updated the KIP by adding more details >>> to it. >>> >>> Regards, >>> Umesh >>> >>> On Mon, 31 Jul 2017 at 21:51 Ewen Cheslack-Postava >>> wrote: >>> >>>> On Sun, Jul 30, 2017 at 10:21 PM, UMESH CHAUDHARY >>>> wrote: >>>> >>>>> Hi Ewen, >>>>> Thanks for your comments. >>>>> >>>>> 1) Yes, there are some test and java classes which refer these >>>>> configs, so I will include them as well in "public interface" section of >>>>> KIP. What should be our approach to deal with the classes and tests which >>>>> use these configs: we need to change them to use JsonConverter when >>>>> we plan for removal of these configs right? >>>>> >>>> >>>> I actually meant the references in config/connect-standalone.properties >>>> and config/connect-distributed.properties >>>> >>>> >>>>> 2) I believe we can target the deprecation in 1.0.0 release as it is >>>>> planned in October 2017 and then removal in next major release. Let >>>>> me know your thoughts as we don't have any information for next major >>>>> release (next to 1.0.0) yet. >>>>> >>>> >>>> That sounds fine. Tough to say at this point what our approach to major >>>> version bumps will be since the approach to version numbering is changing a >>>> bit. >>>> >>>> >>>>> 3) Thats a good point and mentioned JIRA can help us to validate the >>>>> usage of any other converters. I will list this down in the KIP. >>>>> >>>>> Let me know if you have some additional thoughts on this. >>>>> >>>>> Regards, >>>>> Umesh >>>>> >>>>> >>>>> >>>>> On Wed, 26 Jul 2017 at 09:27 Ewen Cheslack-Postava >>>>> wrote: >>>>> >>>>>> Umesh, >>>>>> >>>>>> Thanks for the KIP. Straightforward and I think it's a good change. >>>>>> Unfortunately it is hard to tell how many people it would affect >>>>>> since we >>>>>> can't tell how many people have adjusted that config, but I think >>>>>> this is >>>>>> the right thing to do long term. >>>>>> >>>>>> A couple of quick things that might be helpful to refine: >>>>>> >>>>>> * Note that there are also some references in the example configs >>>>>> that we >>>>>> should remove. >>>>>> * It's nice to be explicit about when the removal is planned. This >>>>>> lets us >>>>>> set expectations with users for timeframe (especially now that we >>>>>> have time >>>>>> based releases), allows us to give info about the removal timeframe >>>>>> in log >>>>>> error messages, and lets us file a JIRA against that release so we >>>>>> remember >>>>>> to follow up. Given the update to 1.0.0 for the next release, we may >>>>>> also >>>>>> need to adjust how we deal with deprecations/removal if we don't want >>>>>> to >>>>>> have to wait all the way until 2.0 to remove (though it is unclear how >>>>>> exactly we will be handling version bumps from now on). >>>>>> * Migration path -- I think this is the major missing gap in the KIP. >>>>>> Do we >>>>>> need a migration path? If not, presumably it is because people aren't >>>>>> using >>>>>> any other converters in practice. Do we have some way of validating >>>>>> this ( >>>>>> https://issues.apache.org/jira/browse/KAFKA-3988 might be pretty >>>>>> convincing >>>>>> evidence)? If there are some users using other converters, how would >>>>>> they >>>>>> migrate to newer versions which would no longer support that? >>>>>> >>>>>> -Ewen >>>>>> >>>>>> >>>>>> On Fri, Jul 14, 2017 at 2:37 AM, UMESH CHAUDHARY >>>>> > >>>>>> wrote: >>>>>> >>>>>> > Hi there, >>>>>> > Resending as probably missed earlier to grab your attention. >>>>>> > >>>>>> > Regards, >>>>>> > Umesh >>>>>> > >>>>>> > ---------- Forwarded message --------- >>>>>> > From: UMESH CHAUDHARY >>>>>> > Date: Mon, 3 Jul 2017 at 11:04 >>>>>> > Subject: [DISCUSS] KIP-174 - Deprecate and remove internal converter >>>>>> > configs in WorkerConfig >>>>>> > To: dev@kafka.apache.org >>>>>> > >>>>>> > >>>>>> > Hello All, >>>>>> > I have added a KIP recently to deprecate and remove internal >>>>>> converter >>>>>> > configs in WorkerConfig.java class because these have ultimately >>>>>> just >>>>>> > caused a lot more trouble and confusion than it is worth. >>>>>> > >>>>>> > Please find the KIP here >>>>>> > >>>>> > 174+-+Deprecate+and+remove+internal+converter+configs+in+ >>>>>> WorkerConfig> >>>>>> > and >>>>>> > the related JIRA here >>>>> jira/browse/KAFKA-5540>. >>>>>> > >>>>>> > Appreciate your review and comments. >>>>>> > >>>>>> > Regards, >>>>>> > Umesh >>>>>> > >>>>>> >>>>> >> --001a11412adace6e200561ff1d1d--