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 >> > >>>>>>>> >> > >>>>>> >> > >>>>> >> > >>> >> > >> >> > >> >
