Hi James, On Sun, May 7, 2017 at 8:36 AM, James Cheng <wushuja...@gmail.com> wrote:
> Makes sense, and I don't have any concerns about it. Actually, I'm excited > for the capability. That means you can completely tell how a topic is > configured, without needing to have any knowledge of how the broker is > configured. > That's the goal indeed. Unrelated to this KIP, but important to keep in mind is that all brokers must have the same topic configs for things to work in a sane manner. That is a peculiarity of how topic configs work in Kafka: the fallback to broker topic configs is done during load, not during store. This makes it possible to update all topic config defaults by updating the config in every broker following by a rolling restart (or by upgrading to a new version of Kafka where broker topic config defaults has changed), but it can also be a source of weird behaviour if the broker topic configs are not consistent. There are a few ways this could be improved, but that's a subject for another KIP. :) You said that "if we fallback to the broker config (whether it's a default > or not), is_default will be true.". I assume that if I were to ListConfig > on the *broker*, then if a config is the kafka default, then is_default > will be true. And if the operator specifically set an override for the > broker config, then is_default will be false? > That's right. If that is all correct, then you can also completely tell how a broker is > configured, without needing to look at its config file. Which is pretty > convenient. > Yeah, that is indeed the goal as well. :) I'll update the KIP to clarify these important points. Thanks, Ismael
