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 <[email protected]> wrote: > Hi Ron, > > Yes, that's what I am proposing, yes. > > Ismael > > On Sat, Sep 30, 2023 at 2:30 PM Ron Dagostino <[email protected]> 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 <[email protected]> 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 <[email protected]> > > 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 <[email protected]> > > 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 <[email protected]> > > >>> 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 <[email protected]> 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 <[email protected]> > > >>> 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 > <[email protected] > > >>> > > >>>>>> 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 < > [email protected] > > >>> > > >>>>>> 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 > > >>> <[email protected]> > > >>>>>>>> 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 > > >>>>>>>> > > >>>>>> > > >>>>> > > >>> > > >> > > >
