Re: [DISCUSS] KIP-979: Allow independently stop KRaft controllers or brokers

Not everything is a broker, though. So --node-id seems better. best, Colin On Sun, Oct 1, 2023, at 23:08, Kamal Chandraprakash wrote: > Hi Hailey, > > Thanks for working on this! This is one of the long-standing open issues. > Now, users have to find the PID of the respective Kafka process to

Re: [DISCUSS] KIP-979: Allow independently stop KRaft controllers or brokers

Hi Federico, Thanks for your comments. SureI will update the KIP accordingly. Thanks, Hailey On Tue, Oct 3, 2023 at 1:29 AM Federico Valeri wrote: > Hi Hailey, thanks for the KIP. > > I also agree that the two mutually exclusive args are better. In order > to be consistent with the other

Re: [DISCUSS] KIP-979: Allow independently stop KRaft controllers or brokers

Hi Hailey, thanks for the KIP. I also agree that the two mutually exclusive args are better. In order to be consistent with the other tools, I would suggest to use --process-role and --node-id (hyphen instead of dot). Can you also update the KIP? On Mon, Oct 2, 2023 at 10:18 PM Hailey Ni wrote:

Re: [DISCUSS] KIP-979: Allow independently stop KRaft controllers or brokers

Hi Kamal, I think the broker.id property has been replaced with the `node.id` property in KRaft. The documentation for `node.id` says it is required ( https://github.com/apache/kafka/blob/72e275f6ea867747e6b4e524c80d5ebd726ac25b/core/src/main/scala/kafka/server/KafkaConfig.scala#L741), and the

Re: [DISCUSS] KIP-979: Allow independently stop KRaft controllers or brokers

Hi Ismeal, Thanks for the comments. I'll change the implementation to use a pair of mutually exclusive args --process.roles and --node.id. Thanks, Hailey On Mon, Oct 2, 2023 at 6:34 AM Ismael Juma wrote: > Hi Ron, > > Yes, that's what I am proposing, yes. > > Ismael > > On Sat, Sep 30, 2023

Re: [DISCUSS] KIP-979: Allow independently stop KRaft controllers or brokers

Hi Ron, Yes, that's what I am proposing, yes. Ismael On Sat, Sep 30, 2023 at 2:30 PM Ron Dagostino wrote: > Thanks, Ismael. I think you are proposing a pair of mutually exclusive > args --process.roles and --node.id, right? I agree that is more > user-friendly than the --required-config

Re: [DISCUSS] KIP-979: Allow independently stop KRaft controllers or brokers

Hi Hailey, Thanks for working on this! This is one of the long-standing open issues. Now, users have to find the PID of the respective Kafka process to stop if more than one node is being run locally for testing purposes. The updated KIP is addressing that. LGTM. Is `node.id` and `broker.id` the

Re: [DISCUSS] KIP-979: Allow independently stop KRaft controllers or brokers

Thanks, Ismael. I think you are proposing a pair of mutually exclusive args --process.roles and --node.id, right? I agree that is more user-friendly than the --required-config arg, and it comes at the possible expense of generality. So that’s the tradeoff between the two, I think. No other

Re: [DISCUSS] KIP-979: Allow independently stop KRaft controllers or brokers

Hi, Thanks for the KIP. I think this approach based on configs is a bit too open ended and not very user friendly. Why don't we simply provide flags for the things a user may care about? So far, it seems like we have two good candidates (node id and process role). Are there any others? Ismael

Re: [DISCUSS] KIP-979: Allow independently stop KRaft controllers or brokers

Hi Ron, I think you made a great point, making the "name" arbitrary instead of hard-coding it will make the functionality much more flexible. I've updated the KIP and the code accordingly. Thanks for the great idea! Thanks, Hailey On Fri, Sep 29, 2023 at 2:34 PM Ron Dagostino wrote: >

Re: [DISCUSS] KIP-979: Allow independently stop KRaft controllers or brokers

Thanks, Hailey. Is there a reason to restrict it to just process.roles and node.id? Someone might want to do "--required-config any.name=whatever.value", for example, and at first glance I don't see a reason why the implementation should be any different -- it seems it would probably be easier

Re: [DISCUSS] KIP-979: Allow independently stop KRaft controllers or brokers

Updated. Please let me know if you have any additional comments. Thank you! On Thu, Sep 21, 2023 at 3:02 PM Hailey Ni wrote: > Hi Ron. Thanks for the response. I agree with your point. I'll make the > corresponding changes in the KIP and KAFKA-15471 >

Re: [DISCUSS] KIP-979: Allow independently stop KRaft controllers or brokers

Hi Ron. Thanks for the response. I agree with your point. I'll make the corresponding changes in the KIP and KAFKA-15471 . On Thu, Sep 21, 2023 at 1:40 PM Ron Dagostino wrote: > Hi Hailey. No, I just looked, and zookeeper-server-stop does not

Re: [DISCUSS] KIP-979: Allow independently stop KRaft controllers or brokers

Hi Hailey. No, I just looked, and zookeeper-server-stop does not have any facility to be specific about which ZK nodes to signal. So providing the ability in kafka-server-stop to be more specific than just "signal all controllers" or "signal all brokers" would be a bonus and therefore not

Re: [DISCUSS] KIP-979: Allow independently stop KRaft controllers or brokers

Hi Ron, Thank you very much for the comment. I think it makes sense to me that we provide an even more specific way to kill individual controllers/brokers. I have one question: does the command line for ZooKeeper cluster provide such a way to kill individual controllers/brokers? Thanks, Hailey

Re: [DISCUSS] KIP-979: Allow independently stop KRaft controllers or brokers

Thanks for the KIP, Hailey. It will be nice to provide some fine-grained control for when people running the broker and controller this way want to stop just one of them. One thing that occurs to me is that in a development environment someone might want to run multiple controllers and multiple

[DISCUSS] KIP-979: Allow independently stop KRaft controllers or brokers

Hi all, I would like to start the discussion about *KIP-979: Allow independently stop KRaft controllers or brokers* < https://cwiki.apache.org/confluence/display/KAFKA/KIP-979%3A+Allow+independently+stop+KRaft+controllers+or+brokers > It proposes adding an optional field "--process.roles " in the