Page History

...

• Impacts: Controller requests will not longer be blocked by data requests, which should mitigate the effect of stale metadata listed in the motivation section.
• Migration plan: during rolling deployment of the proposed change, four different combinations of <controller, broker> can be experienced, and we will discuss each combination in this section. We'll refer to a broker without the proposed change as an old broker, and one with the chance as a new broker. Similarly, we will refer to a controller with the change as a new controller, and one without the change as an old controller.
• <old controller, old broker>: the logic should work the same way as today with controller requests potentially blocked by data requests
• <old controller, new broker>: the new broker will start listening on dedicated on controller endpoints, however the old controller will not use the new endpoints for establishing connections. Being the old controller, it will still use the shared endpoints that are also being used for data requests. The end result should be the same behavior as today.
<new controller, old broker>: In this scenario, the controller will have 2 rounds of rolling upgrades are needed to pick up the proposed changes in this KIP. The goal of the first round is to add the controller endpoint, without adding the "controller.listener.name" config. Specifically, an endpoint with the controller listener name should be added to the "listeners" config, e.g. "CONTROLLER://192.1.1.8:9091"; if the "advertised.listeners" config is explicitly configured and is not getting its value from "listeners", the new endpoint for controller should also be added to "advertised.listeners". After the first round is completed, controller to brokers communication should still behave in the same way that uses the inter-broker-listener-name, since the "controller.listener.name" config set to a value like "CONTROLLER", however the broker's exposed endpoints do not have an entry corresponding to the new listener name. Hence the controller should preserve the existing behavior by determining the endpoint using inter-broker-listener-name value. The end result should be the same behavior as today.<new controller, new broker>: In this case, the proposed change will take effect, and the new dedicated endpoints for controller connections will be used.
After one round of rolling upgrade, all servers in a cluster should have the proposed change, and start using the new dedicated endpoints for controller connections. No 2nd round of rolling upgrade is requiredis not set yet. In the 2nd round, the "controller.listener.name" config should be set to the corresponding listener name, e.g. "CONTROLLER". During rolling upgrade of the 2nd round, controller to brokers traffic will start using the "controller.listener.name", and go through the proposed changes in this KIP.
• No special migration tools are needed.
• The existing behavior will be removed after the PR is merged in.

...