Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
3.0.0
-
None
-
None
-
None
Description
Plugins may expect broker.id to exist as a key in the config's various originals()-related maps, but with KRaft we rely solely on node.id for the broker's ID, and with the Zk-based brokers we provide the option to specify node.id in addition to (or as a full replacement for) broker.id.
There are multiple problems related to this switch to node.id:
- We do not enforce consistency between explicitly-specified broker.id and node.id properties in the config – it is entirely possible right now that we could set broker.id=0 and also set node.id=1, and the broker will use 1 for it's ID. This is confusing at best; the broker should detect this inconsistency and fail to start with a ConfigException.
- When node.id is set, both that value and any explicitly-set broker.id value will exist in the config's originals()-related maps. Downstream components are often configured based on these maps, and they may ask for the broker.id, so downstream components may be misconfigured if the values differ, or they may fail during configuration if no broker.id key exists in the map at all.
- The config's values()-related maps will contain either the explicitly-specified broker.id value or the default value of -1. When node.id is set, both that value (which cannot be negative) and the (potentially -1) broker.id value will exist in the config's values()-related maps. Downstream components are often configured based on these maps, and they may ask for the broker.id, so downstream components may be misconfigured if the broker.id value differs from the broker's true ID.
The broker should detect inconsistency between explicitly-specified broker.id and node.id values and fail startup accordingly. It should also ensures that the config's originals()- and values()-related maps contain the same mapped values for both broker.id and node.id keys.