Hi Luke, Appreciate the feedback — glad to finally see some voices in this thread! :)
*L01, L02:* Sure thing! *L03:* Thanks for the heads-up — I hadn’t thought of that before. In KAFKA-19563, you mentioned introducing a new --add-controller-command-config option to separate admin and controller configs. That sounds like a solid approach. That said, I was thinking of an alternative: what if we change the logic so that *when both* --command-config *and* --controller-id are provided, the command config only applies to admin initialization? Users can add extra admin properties in --command-config. What do you think? *L04:* Yeah, I agree — to make things easier, we could enhance the logic. If the user provides --bootstrap-server, we can retrieve controller.quorum.bootstrap.servers from the broker configs using admin.describeConfigs, and use that to get the required controller configs. Then we could allow users to run something like: bin/kafka-metadata-quorum.sh --bootstrap-server localhost:9092 \ add-controller --controller-id <id> Best, Kuan-Po On Thu, Jul 31, 2025 at 3:24 PM Luke Chen <show...@gmail.com> wrote: > Hi Kuan-Po, > > Thanks for the KIP! > We also faced the similar issue recently. > > Some suggestions/questions: > 1. Could you also include the issue in KAFKA-19563 > <https://issues.apache.org/jira/browse/KAFKA-19563> as the motivation in > the KIP? > 2. Could you make it clear in the KIP that after the KIP, the > add-controller request from kafka-metadata-quorum.sh will take more time > than before because of more API calls needed? > 3. "If —-command-config is provided, fallback to the existing behavior, and > —-controller-id option will be ignored." > On this, it looks like it still doesn't resolve the issue described in > KAFKA-19563 <https://issues.apache.org/jira/browse/KAFKA-19563> because if > the client wants to pass the "client.id", and provide a properties file in > --command-config, it 'll be treated as the controller.properties and fail > the request, right? Ex: > `bin/kafka-metadata-quorum.sh --bootstrap-controller localhost:9093 > add-controller --controller-id <id> --command-config admin.properties` > 4. "This can only be done with bootstrap controller option since we can‘t > use bootstrap.server in Admin#describeConfigs to get controller configs." > I understand the reason but it makes the script more confusing in my > opinion. > I'm wondering why we need the controller endpoint when talking with the > broker with --bootstrap-server? The controller endpoint should already > exist in broker itself, right? > > Thank you. > Luke > > On Sat, Apr 19, 2025 at 11:32 PM Kuan Po Tseng <brandb...@apache.org> > wrote: > > > Hi José, > > > > Apologies for the delayed response. Do you still have any questions > > regarding the describeConfig part? As Chia-Ping mentioned, we are able to > > retrieve all broker configurations through that method. ( > > > https://github.com/apache/kafka/blob/da46cf6e79afbbed1da2bae831e0f70992e85f9b/core/src/main/scala/kafka/server/ConfigHelper.scala#L121-L123 > > ) > > > > Please feel free to reach out if you have any further questions or need > > clarification. Thank you again for your valuable feedback! > > > > Best, > > Kuan-Po Tseng > > > > On 2025/04/03 16:04:36 José Armando García Sancio wrote: > > > Hi Chia, > > > > > > On Thu, Apr 3, 2025 at 10:24 AM Chia-Ping Tsai <chia7...@apache.org> > > wrote: > > > > We propose to use `Admin#describeConfigs` to get the configs for > > specific controller if the bootstrap.controllers is configured. This > > approach is similar to what `MetadataQuorumCommand` does, and the > > difference is `MetadataQuorumCommand` read those configs from local file > > and this KIP gets those configs by `Admin#describeConfigs` > > > > > > I am not sure. I have to look at that code but doesn't > > > "Admin#describeConfigs" only return dynamic configuration for the > > > controller? Most users configure the controller using the server > > > properties file. My current understanding is that values coming from > > > the properties file won't show up in Admin#describeConfigs. > > > > > > Thanks, > > > -- > > > -José > > > > > >
