kafka-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ewen Cheslack-Postava <e...@confluent.io>
Subject Re: [DISCUSS] KIP-174 - Deprecate and remove internal converter configs in WorkerConfig
Date Fri, 05 Jan 2018 03:33:47 GMT
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 <umesh9794@gmail.com> 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 <ewen@confluent.io>
> 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 <umesh9794@gmail.com>
>> 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 <ewen@confluent.io>
>>> wrote:
>>>
>>>> On Sun, Jul 30, 2017 at 10:21 PM, UMESH CHAUDHARY <umesh9794@gmail.com>
>>>> 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 <ewen@confluent.io>
>>>>> 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 <umesh9794@gmail.com
>>>>>> >
>>>>>> wrote:
>>>>>>
>>>>>> > Hi there,
>>>>>> > Resending as probably missed earlier to grab your attention.
>>>>>> >
>>>>>> > Regards,
>>>>>> > Umesh
>>>>>> >
>>>>>> > ---------- Forwarded message ---------
>>>>>> > From: UMESH CHAUDHARY <umesh9794@gmail.com>
>>>>>> > 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 <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
>>>>>> > <https://cwiki.apache.org/confluence/display/KAFKA/KIP-
>>>>>> > 174+-+Deprecate+and+remove+internal+converter+configs+in+
>>>>>> WorkerConfig>
>>>>>> > and
>>>>>> > the related JIRA here <https://issues.apache.org/
>>>>>> jira/browse/KAFKA-5540>.
>>>>>> >
>>>>>> > Appreciate your review and comments.
>>>>>> >
>>>>>> > Regards,
>>>>>> > Umesh
>>>>>> >
>>>>>>
>>>>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message