You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@kafka.apache.org by UMESH CHAUDHARY <um...@gmail.com> on 2017/07/14 09:37:45 UTC
[DISCUSS] KIP-174 - Deprecate and remove internal converter configs
in WorkerConfig
Hi there,
Resending as probably missed earlier to grab your attention.
Regards,
Umesh
---------- Forwarded message ---------
From: UMESH CHAUDHARY <um...@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 <de...@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
Re: [DISCUSS] KIP-174 - Deprecate and remove internal converter
configs in WorkerConfig
Posted by UMESH CHAUDHARY <um...@gmail.com>.
Thanks Ewen, and apologies as I missed this too. I'll start vote for this
soon and proceed for the next steps.
On Fri, 5 Jan 2018 at 09:03 Ewen Cheslack-Postava <ew...@confluent.io> wrote:
> 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 <um...@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 <ew...@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 <um...@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 <ew...@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 <ew...@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 <um...@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 <de...@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
>>>>>>> >
>>>>>>>
>>>>>>
>>>
>
Re: [DISCUSS] KIP-174 - Deprecate and remove internal converter
configs in WorkerConfig
Posted by UMESH CHAUDHARY <um...@gmail.com>.
Thanks Ewen, and apologies as I missed this too. I'll start vote for this
soon and proceed for the next steps.
On Fri, 5 Jan 2018 at 09:03 Ewen Cheslack-Postava <ew...@confluent.io> wrote:
> 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 <um...@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 <ew...@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 <um...@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 <ew...@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 <ew...@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 <um...@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 <de...@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
>>>>>>> >
>>>>>>>
>>>>>>
>>>
>
Re: [DISCUSS] KIP-174 - Deprecate and remove internal converter
configs in WorkerConfig
Posted by Ewen Cheslack-Postava <ew...@confluent.io>.
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 <um...@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 <ew...@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 <um...@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 <ew...@confluent.io>
>>> wrote:
>>>
>>>> On Sun, Jul 30, 2017 at 10:21 PM, UMESH CHAUDHARY <um...@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 <ew...@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 <um...@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 <de...@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
>>>>>> >
>>>>>>
>>>>>
>>
Re: [DISCUSS] KIP-174 - Deprecate and remove internal converter
configs in WorkerConfig
Posted by Ewen Cheslack-Postava <ew...@confluent.io>.
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 <um...@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 <ew...@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 <um...@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 <ew...@confluent.io>
>>> wrote:
>>>
>>>> On Sun, Jul 30, 2017 at 10:21 PM, UMESH CHAUDHARY <um...@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 <ew...@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 <um...@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 <de...@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
>>>>>> >
>>>>>>
>>>>>
>>
Re: [DISCUSS] KIP-174 - Deprecate and remove internal converter
configs in WorkerConfig
Posted by UMESH CHAUDHARY <um...@gmail.com>.
Thanks Ewen,
I just edited the KIP to reflect the changes.
Regards,
Umesh
On Wed, 9 Aug 2017 at 11:00 Ewen Cheslack-Postava <ew...@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 <um...@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 <ew...@confluent.io>
>> wrote:
>>
>>> On Sun, Jul 30, 2017 at 10:21 PM, UMESH CHAUDHARY <um...@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 <ew...@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 <um...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> > Hi there,
>>>>> > Resending as probably missed earlier to grab your attention.
>>>>> >
>>>>> > Regards,
>>>>> > Umesh
>>>>> >
>>>>> > ---------- Forwarded message ---------
>>>>> > From: UMESH CHAUDHARY <um...@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 <de...@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
>>>>> >
>>>>>
>>>>
>
Re: [DISCUSS] KIP-174 - Deprecate and remove internal converter
configs in WorkerConfig
Posted by UMESH CHAUDHARY <um...@gmail.com>.
Thanks Ewen,
I just edited the KIP to reflect the changes.
Regards,
Umesh
On Wed, 9 Aug 2017 at 11:00 Ewen Cheslack-Postava <ew...@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 <um...@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 <ew...@confluent.io>
>> wrote:
>>
>>> On Sun, Jul 30, 2017 at 10:21 PM, UMESH CHAUDHARY <um...@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 <ew...@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 <um...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> > Hi there,
>>>>> > Resending as probably missed earlier to grab your attention.
>>>>> >
>>>>> > Regards,
>>>>> > Umesh
>>>>> >
>>>>> > ---------- Forwarded message ---------
>>>>> > From: UMESH CHAUDHARY <um...@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 <de...@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
>>>>> >
>>>>>
>>>>
>
Re: [DISCUSS] KIP-174 - Deprecate and remove internal converter
configs in WorkerConfig
Posted by Ewen Cheslack-Postava <ew...@confluent.io>.
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 <um...@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 <ew...@confluent.io>
> wrote:
>
>> On Sun, Jul 30, 2017 at 10:21 PM, UMESH CHAUDHARY <um...@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 <ew...@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 <um...@gmail.com>
>>>> wrote:
>>>>
>>>> > Hi there,
>>>> > Resending as probably missed earlier to grab your attention.
>>>> >
>>>> > Regards,
>>>> > Umesh
>>>> >
>>>> > ---------- Forwarded message ---------
>>>> > From: UMESH CHAUDHARY <um...@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 <de...@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
>>>> >
>>>>
>>>
Re: [DISCUSS] KIP-174 - Deprecate and remove internal converter
configs in WorkerConfig
Posted by Ewen Cheslack-Postava <ew...@confluent.io>.
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 <um...@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 <ew...@confluent.io>
> wrote:
>
>> On Sun, Jul 30, 2017 at 10:21 PM, UMESH CHAUDHARY <um...@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 <ew...@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 <um...@gmail.com>
>>>> wrote:
>>>>
>>>> > Hi there,
>>>> > Resending as probably missed earlier to grab your attention.
>>>> >
>>>> > Regards,
>>>> > Umesh
>>>> >
>>>> > ---------- Forwarded message ---------
>>>> > From: UMESH CHAUDHARY <um...@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 <de...@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
>>>> >
>>>>
>>>
Re: [DISCUSS] KIP-174 - Deprecate and remove internal converter
configs in WorkerConfig
Posted by UMESH CHAUDHARY <um...@gmail.com>.
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 <ew...@confluent.io>
wrote:
> On Sun, Jul 30, 2017 at 10:21 PM, UMESH CHAUDHARY <um...@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 <ew...@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 <um...@gmail.com>
>>> wrote:
>>>
>>> > Hi there,
>>> > Resending as probably missed earlier to grab your attention.
>>> >
>>> > Regards,
>>> > Umesh
>>> >
>>> > ---------- Forwarded message ---------
>>> > From: UMESH CHAUDHARY <um...@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 <de...@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
>>> >
>>>
>>
Re: [DISCUSS] KIP-174 - Deprecate and remove internal converter
configs in WorkerConfig
Posted by UMESH CHAUDHARY <um...@gmail.com>.
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 <ew...@confluent.io>
wrote:
> On Sun, Jul 30, 2017 at 10:21 PM, UMESH CHAUDHARY <um...@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 <ew...@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 <um...@gmail.com>
>>> wrote:
>>>
>>> > Hi there,
>>> > Resending as probably missed earlier to grab your attention.
>>> >
>>> > Regards,
>>> > Umesh
>>> >
>>> > ---------- Forwarded message ---------
>>> > From: UMESH CHAUDHARY <um...@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 <de...@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
>>> >
>>>
>>
Re: [DISCUSS] KIP-174 - Deprecate and remove internal converter
configs in WorkerConfig
Posted by Ewen Cheslack-Postava <ew...@confluent.io>.
On Sun, Jul 30, 2017 at 10:21 PM, UMESH CHAUDHARY <um...@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 <ew...@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 <um...@gmail.com>
>> wrote:
>>
>> > Hi there,
>> > Resending as probably missed earlier to grab your attention.
>> >
>> > Regards,
>> > Umesh
>> >
>> > ---------- Forwarded message ---------
>> > From: UMESH CHAUDHARY <um...@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 <de...@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
>> >
>>
>
Re: [DISCUSS] KIP-174 - Deprecate and remove internal converter
configs in WorkerConfig
Posted by Ewen Cheslack-Postava <ew...@confluent.io>.
On Sun, Jul 30, 2017 at 10:21 PM, UMESH CHAUDHARY <um...@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 <ew...@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 <um...@gmail.com>
>> wrote:
>>
>> > Hi there,
>> > Resending as probably missed earlier to grab your attention.
>> >
>> > Regards,
>> > Umesh
>> >
>> > ---------- Forwarded message ---------
>> > From: UMESH CHAUDHARY <um...@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 <de...@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
>> >
>>
>
Re: [DISCUSS] KIP-174 - Deprecate and remove internal converter
configs in WorkerConfig
Posted by UMESH CHAUDHARY <um...@gmail.com>.
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?
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.
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 <ew...@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 <um...@gmail.com>
> wrote:
>
> > Hi there,
> > Resending as probably missed earlier to grab your attention.
> >
> > Regards,
> > Umesh
> >
> > ---------- Forwarded message ---------
> > From: UMESH CHAUDHARY <um...@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 <de...@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
> >
>
Re: [DISCUSS] KIP-174 - Deprecate and remove internal converter
configs in WorkerConfig
Posted by UMESH CHAUDHARY <um...@gmail.com>.
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?
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.
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 <ew...@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 <um...@gmail.com>
> wrote:
>
> > Hi there,
> > Resending as probably missed earlier to grab your attention.
> >
> > Regards,
> > Umesh
> >
> > ---------- Forwarded message ---------
> > From: UMESH CHAUDHARY <um...@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 <de...@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
> >
>
Re: [DISCUSS] KIP-174 - Deprecate and remove internal converter
configs in WorkerConfig
Posted by Ewen Cheslack-Postava <ew...@confluent.io>.
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 <um...@gmail.com>
wrote:
> Hi there,
> Resending as probably missed earlier to grab your attention.
>
> Regards,
> Umesh
>
> ---------- Forwarded message ---------
> From: UMESH CHAUDHARY <um...@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 <de...@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
>
Re: [DISCUSS] KIP-174 - Deprecate and remove internal converter
configs in WorkerConfig
Posted by Ewen Cheslack-Postava <ew...@confluent.io>.
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 <um...@gmail.com>
wrote:
> Hi there,
> Resending as probably missed earlier to grab your attention.
>
> Regards,
> Umesh
>
> ---------- Forwarded message ---------
> From: UMESH CHAUDHARY <um...@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 <de...@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
>