...

1. 1. (if upgrading  from 0.8.2.0 or earlier, add inter.broker.protocol.version=0.8.2.0 to configuration file, otherwise wire protocol will default to the latest version and we will not be able to do a rolling upgrade.)
   2. do a rolling upgrade on the brokers first
   3. bump version of inter.broker.protocol.version to current version (0.8.3.0 or 0.9.0.0 depending on release)
   4. If desired additional ports / security protocols can be added using the new "listeners" configuration parameter.
   5. Clients can be upgraded whenever is convenient. 
      
      Only "plaintext" protocol is supported until broker upgrade is complete. Also, only upgraded clients will be able to use new security protocols.
      
      

• When will we remove the existing behavior?
  We plan to continue supporting existing behavior (i.e. a single "plaintext" host+port) indefinitely.

Clarification regarding the wire protocol version and the upgrade process:

The issue is the following:

In 0.8.3, we will be evolving the wire protocol of UpdateMedataRequest (to send info about endpoints for different security protocols). Since this is used in intra-cluster communication, we need to do the upgrade in two steps.

The idea is that in 0.8.3, we will default wire.protocol.version to 0.8.2. When upgrading to 0.8.3, in step 1, we do a rolling upgrade to 0.8.3.

After step1, all brokers will be capable for processing the new protocol in 0.8.3, but without actually using it.

In step 2, we configure wire.protocol.version to 0.8.3 in each broker and do another rolling restart.

After step 2, all brokers will start using the new protocol in 0.8.3.

Let's say that in the next release 0.9, we are changing the intra-cluster wire protocol again. We will do the similar thing:

...

• .

Rejected Alternatives

There was considerable discussion of the possibility of supporting all security protocols on the same port simultaneously. This was rejected for the following reasons:

...