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

Ismael Juma commented on KAFKA-7481:
------------------------------------

Using KIP-35 to negotiate protocols is something that has been discussed and 
something we want to do, but [~hachikuji] pointed out that we need to think it 
through to make sure it works. Another way to avoid two restarts is to use 
dynamic broker configs to bump the inter.broker.protocol.version. I am still 
not sure if there's a lot of value in having two separate upgrade states, but 
could be convinced otherwise.

> 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