[
https://issues.apache.org/jira/browse/KAFKA-7481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16669120#comment-16669120
]
Jason Gustafson commented on KAFKA-7481:
----------------------------------------
I am also in favor of option 1 for the time being. While writing the KIP above,
I felt the actual benefit to having a separate configuration was marginal and
probably not worth the upgrade complexity that it adds. Note that I filed
KAFKA-7570 to explore better options for managing the compatibility of the
internal topic schemas. If we could figure that out, then we may not ultimately
need the separate configuration. This discussion has also made it clear that we
need a consistent and tested approach for downgrading Kafka. I also filed
KAFKA-7571 to add system tests, which are lacking at the moment. Then we just
need to agree on the long-term approach and document it.
For now, I will go ahead and submit a PR to add some additional upgrade notes
mentioning the incompatible changes to the offsets schema and the impact for
downgrades.
> 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)
