On Sun, Apr 9, 2023, at 19:17, Ismael Juma wrote:
>
> On Sun, Apr 9, 2023 at 4:53 PM Colin McCabe <cmcc...@apache.org> wrote:
>
>> We are going to deprecate ZK mode soon. So if this is indeed a requirement
>> (no deprecated software in prod), perhaps those users will have to move to
>> KRaft mode. (Independently of what we decide here)
>>
>
> Not sure where "no deprecated software in prod" is coming from. The concern
> is regarding end-of-life software - i.e. software that no longer receives
> security fixes. If we don't upgrade beyond 3.6.x, we'll be in a tough
> position when a CVE is fixed only in ZooKeeper 3.7.x, 3.8.x, etc. If it's a
> serious security problem, then it's likely that an additional release of
> ZooKeeper 3.6.x might be released. But the more likely case is that a
> library dependency will have a CVE that will trigger the compliance checks
> from enterprise users, but not warrant another ZooKeeper 3.6.x release.

Hi Ismael,

Fair enough. There is a difference between deprecated and unsupported. ZK 3.6.x 
is unsupported which is worse than deprecated, since it means it will not be 
updated.

Overall, I agree with you that we're going to have to move to the new version 
of ZK. This fits in with the overall timeline of one more year of Kafka 
releases supporting ZK. If Apache Kafka 4.0 is April 2024, we'll need to be 
getting security updates for ZK during this time.

On Wed, Apr 12, 2023, at 08:45, Christo Lolov wrote:
> Hello Colin,
>
> Thank you for the response!
>
> 1. I have attached the compatibility matrix in the KIP under the section
> Compatibility, Deprecation, and Migration Plan.

Hi Christo,

Thanks for attaching the matrix to the KIP.

I don't understand why Kafka clients are part of this matrix. The Kafka client 
doesn't use ZK directly. (Well, certain very ancient pre-1.0 Kafka clients did, 
but that was a long time ago). So let's remove this.

If I understand this correctly, the main documentation that will be needed is 
for pre-2.4 Kafka releases. Assuming they keep everything "stock" (which in my 
experience most users do), the net-net is that pre-2.4 releases need to make an 
extra hop through a post-2.4, pre-3.6 release. We will have to document that as 
prominently as we can.

I am +1 for this with the proviso that we do it in 3.6. We should update the 
version as soon as we can post-3.5 so that any bugs shake out as soon as 
possible.

best,
Colin

Reply via email to