[ 
https://issues.apache.org/jira/browse/KAFKA-7481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16657718#comment-16657718
 ] 

Jason Gustafson commented on KAFKA-7481:
----------------------------------------

[~lindong] [~ijuma] For consideration, I drafted a short KIP: 
https://cwiki.apache.org/confluence/display/KAFKA/KIP-384%3A+Add+config+for+incompatible+changes+to+persistent+metadata.
 We could either try to get this in for this release or choose one of the other 
options for now. I think long term we should probably have something like this, 
so if we can agree on the approach, perhaps now is as good of a time as any.

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

Reply via email to