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 same? If yes, can we rename it to `
broker.id` instead?

--
Kamal



On Sun, Oct 1, 2023 at 3:00 AM 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
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>
> >>
>

Reply via email to