[
https://issues.apache.org/jira/browse/KAFKA-7481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663144#comment-16663144
]
Ewen Cheslack-Postava commented on KAFKA-7481:
----------------------------------------------
[~lindong] I think anything here ends up having at least *some* blocker
component for 2.1 because we're either a) changing the previously understood
(even if not promised) semantics for a setting or b) need to at least do some
docs/upgrade notes clarifications.
I think we may also need to consider both short and long term solutions.
Anything relying on KIP-35 to check inter-broker protocol compatibility seems
like not a good idea for 2.1 this late in the release cycle. (I mentioned for
completeness & getting to a good long term solution even if we have a
short-term hack, but I don't think that's a practical change to get into 2.1 at
this point.) Also, even if we switch to using KIP-35, there's a whole
compatibility story wrt existing settings that would need to be worked out.
re: your specific proposal, it generally sounds reasonable but wrt testing
surface area, it actually does increase it to some degree because we would need
tests that validate correct behavior via KIP-35 checks while upgrading.
Longer term, I definitely think making things "just work" rather than having
the user manage protocol versions manually during upgrade is better. Just not
sure we can actually make that happen immediately for this release.
> Consider options for safer upgrade of offset commit value schema
> ----------------------------------------------------------------
>
> Key: KAFKA-7481
> URL: https://issues.apache.org/jira/browse/KAFKA-7481
> Project: Kafka
> Issue Type: Bug
> Reporter: Jason Gustafson
> Priority: Blocker
> Fix For: 2.1.0
>
>
> KIP-211 and KIP-320 add new versions of the offset commit value schema. The
> use of the new schema version is controlled by the
> `inter.broker.protocol.version` configuration. Once the new inter-broker
> version is in use, it is not possible to downgrade since the older brokers
> will not be able to parse the new schema.
> The options at the moment are the following:
> 1. Do nothing. Users can try the new version and keep
> `inter.broker.protocol.version` locked to the old release. Downgrade will
> still be possible, but users will not be able to test new capabilities which
> depend on inter-broker protocol changes.
> 2. Instead of using `inter.broker.protocol.version`, we could use
> `message.format.version`. This would basically extend the use of this config
> to apply to all persistent formats. The advantage is that it allows users to
> upgrade the broker and begin using the new inter-broker protocol while still
> allowing downgrade. But features which depend on the persistent format could
> not be tested.
> Any other options?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
