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 <fedeval...@gmail.com> 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 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 <h...@confluent.io.invalid> > wrote: > > > > 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 QuickStart files all use it ( > > > https://github.com/apache/kafka/tree/72e275f6ea867747e6b4e524c80d5ebd726ac25b/config/kraft > ). > > It is technically true that these two configs are treated as synonyms of > > one another ( > > > https://github.com/apache/kafka/blob/72e275f6ea867747e6b4e524c80d5ebd726ac25b/core/src/main/scala/kafka/server/KafkaConfig.scala#L1587-L1597 > ), > > so if you specify either one the process will still recognize it and > > start. But it makes sense to exclusively use `node.id` in KRaft > because a > > node isn't necessarily a broker anymore; it could be a controller (or > even > > a combined broker+controller). > > > > Thanks, > > Hailey > > > > On Mon, Oct 2, 2023 at 1:17 PM Hailey Ni <h...@confluent.io> wrote: > > > > > 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 <m...@ismaeljuma.com> wrote: > > > > > >> Hi Ron, > > >> > > >> Yes, that's what I am proposing, yes. > > >> > > >> Ismael > > >> > > >> On Sat, Sep 30, 2023 at 2:30 PM Ron Dagostino <rndg...@gmail.com> > 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 arg, and it comes at the > > >> possible > > >> > expense of generality. So that’s the tradeoff between the two, I > think. > > >> > No other config comes to mind now that we’ve identified these two. > I > > >> think > > >> > the two specific and mutually exclusive parameters would be the way > to > > >> go > > >> > unless someone else identifies still more options that people might > > >> want. > > >> > > > >> > Did I get that right, or were you proposing something different? > > >> > > > >> > Ron > > >> > > > >> > > On Sep 30, 2023, at 10:42 AM, Ismael Juma <m...@ismaeljuma.com> > wrote: > > >> > > > > >> > > 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 > > >> > > > > >> > >> On Fri, Sep 29, 2023 at 6:19 PM Hailey Ni > <h...@confluent.io.invalid> > > >> > wrote: > > >> > >> > > >> > >> 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 < > rndg...@gmail.com> > > >> > wrote: > > >> > >>> > > >> > >>> 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 to not have to > > >> worry > > >> > >>> about restricting to specific cases, actually. WDYT? > > >> > >>> > > >> > >>> Ron > > >> > >>> > > >> > >>> On Fri, Sep 29, 2023 at 5:12 PM Hailey Ni > <h...@confluent.io.invalid > > >> > > > >> > >>> wrote: > > >> > >>>> > > >> > >>>> Updated. Please let me know if you have any additional > comments. > > >> Thank > > >> > >>> you! > > >> > >>>> > > >> > >>>> On Thu, Sep 21, 2023 at 3:02 PM Hailey Ni <h...@confluent.io> > > >> wrote: > > >> > >>>> > > >> > >>>>> Hi Ron. Thanks for the response. I agree with your point. I'll > > >> make > > >> > >> the > > >> > >>>>> corresponding changes in the KIP and KAFKA-15471 > > >> > >>>>> <https://issues.apache.org/jira/browse/KAFKA-15471>. > > >> > >>>>> > > >> > >>>>> On Thu, Sep 21, 2023 at 1:40 PM Ron Dagostino < > rndg...@gmail.com> > > >> > >>> wrote: > > >> > >>>>> > > >> > >>>>>> 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 necessarily required. But if it is easy to > > >> > >> achieve > > >> > >>>>>> and doesn't add any additional cognitive load -- and at first > > >> glance > > >> > >>>>>> it does seem so -- we should probably just support it. > > >> > >>>>>> > > >> > >>>>>> Ron > > >> > >>>>>> > > >> > >>>>>> On Wed, Sep 20, 2023 at 6:15 PM Hailey Ni > > >> <h...@confluent.io.invalid > > >> > >>> > > >> > >>>>>> wrote: > > >> > >>>>>>> > > >> > >>>>>>> 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 > > >> > >>>>>>> > > >> > >>>>>>> On Tue, Sep 19, 2023 at 11:01 AM Ron Dagostino < > > >> rndg...@gmail.com > > >> > >>> > > >> > >>>>>> wrote: > > >> > >>>>>>> > > >> > >>>>>>>> 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 > > >> > >>> brokers > > >> > >>>>>>>> all on the same box, and in that case they might want to > > >> > >> actually > > >> > >>> stop > > >> > >>>>>>>> just one controller or just one broker instead of all of > them. > > >> > >>> So I'm > > >> > >>>>>>>> wondering if maybe instead of supporting kafka-server-stop > > >> > >>>>>>>> [--process.roles <value>] we might want to instead support > > >> > >>>>>>>> kafka-server-stop [--required-config <name=value>]. If > someone > > >> > >>> wanted > > >> > >>>>>>>> to stop any/all controllers and not touch the broker(s) > they > > >> > >> could > > >> > >>>>>>>> still achieve that by invoking kafka-server-stop > > >> > >> --required-config > > >> > >>>>>>>> process.roles=controller. But if they did want to stop a > > >> > >>> particular > > >> > >>>>>>>> controller they could then also achieve that via > > >> > >> kafka-server-stop > > >> > >>>>>>>> --required-config node.id=1 (for example). What do you > think? > > >> > >>>>>>>> > > >> > >>>>>>>> Ron > > >> > >>>>>>>> > > >> > >>>>>>>> On Thu, Sep 14, 2023 at 5:56 PM Hailey Ni > > >> > >>> <h...@confluent.io.invalid> > > >> > >>>>>>>> wrote: > > >> > >>>>>>>>> > > >> > >>>>>>>>> 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 > <value>" > > >> > >>> in > > >> > >>>>>> the > > >> > >>>>>>>>> script to allow users to independently stop either KRaft > > >> > >> broker > > >> > >>>>>> processes > > >> > >>>>>>>>> or controller processes. While in the past, all processes > were > > >> > >>>>>> killed > > >> > >>>>>>>> using > > >> > >>>>>>>>> a single script. > > >> > >>>>>>>>> Please let me know if you have any questions or comments. > Much > > >> > >>>>>>>> appreciated. > > >> > >>>>>>>>> > > >> > >>>>>>>>> Thanks & Regards, > > >> > >>>>>>>>> Hailey > > >> > >>>>>>>> > > >> > >>>>>> > > >> > >>>>> > > >> > >>> > > >> > >> > > >> > > > >> > > > >
