[
https://issues.apache.org/jira/browse/KAFKA-7481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16655701#comment-16655701
]
Jason Gustafson commented on KAFKA-7481:
----------------------------------------
[~ijuma] [~lindong] Thanks for the responses. I find myself leaning toward
using a separate configuration as a long-term solution. There are two basic
problems with reusing the `log.message.format.version`. First, it can be
overridden at the topic level, which does not make sense for "global" message
schemas like the consumer offsets. Second, its usage is tied to performance
concerns (in particular down-conversion), which are not directly related to
whether or not downgrade should be supported. In any case, my feeling is that
we probably need a KIP and a larger discussion before either making a semantic
change to one of the configs or adding a new config.
In order to unblock the release, I am wondering if we can do option 1. It might
not be ideal, but it is consistent with how we have upgraded internal schemas
in the past (this is how we have handled previous bumps to the
__consumer_offsets schemas). We could add some additional upgrade notes to
emphasize that downgrade is not possible after changing the inter-broker
protocol version. What do you think?
> 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)
