[ 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)