Hey all,

It's that time of year again where we re-restart this vote thread after
some additional
discussions on the disco thread and minor adjustments&clarifications to the
KIP.

We're currently at +5 (non-binding) and -1 (non-binding) votes.

Please cast your votes, people.


Thanks,
Magnus


Den tors 3 mars 2022 kl 15:39 skrev Julien Chanaud <chanaud.jul...@gmail.com
>:

> +1
> As a member of a team which operates several Kafka clusters, I am
> unequipped when it comes to troubleshooting issues with project teams
> that did not understand the importance of configuring client-side
> monitoring.
> Kafka represents a fraction of their work and they don't have enough
> experience, time or interest in trying to understand the meaning behind
> every metric.
>
> I stand 100% behind what Colin stated back in June in the Discuss thread :
>
> > Magnus and I explained a few times the reasons why it does matter. Within
> > most organizations, there are usually several teams using clients, which
> > are separate from the team which maintains the Kafka cluster. The Kafka
> > team has the Kafka experts, which makes it the best place to centralize
> > collecting and analyzing Kafka metrics.
>
>
> Thanks for this KIP.
>
> Le mer. 26 janv. 2022 à 16:01, rifer...@riferrei.com <
> rifer...@riferrei.com>
> a écrit :
>
> > +1
> >
> > I think this KIP solves a problem that has been around for some time with
> > Kafka deployments, which is the ability to assess the current state of a
> > Kafka architecture but looking at the whole picture. I also share other
> > folks' concerns regarding adding runtime dependencies to the clients;
> this
> > may be problematic for large deployments. Still, I think it is worth
> > refactoring.
> >
> > IMHO, it is a fair trade-off.
> >
> > — Ricardo
> >
> > > On Jan 26, 2022, at 9:34 AM, Magnus Edenhill <mag...@edenhill.se>
> wrote:
> > >
> > > Hi all,
> > >
> > > it's been a while and there's been some more discussions of the KIP
> which
> > > have been
> > > addressed on the KIP page.
> > >
> > > I think it's a good time to revive this vote thread and get things
> > moving.
> > >
> > > We're currently at +3 (non-binding) and -1 (non-binding) votes.
> > >
> > > Regards,
> > > Magnus
> > >
> > >
> > > Den mån 1 nov. 2021 kl 21:19 skrev J Rivers <jrivers...@gmail.com>:
> > >
> > >> +1
> > >>
> > >> Thank you for the KIP!
> > >>
> > >> Our organization runs kafka at large scale in a multi-tenant
> > configuration.
> > >> We actually have many other enterprises connecting up to our system to
> > >> retrieve stream data. These feeds vary greatly in volume and velocity.
> > The
> > >> peak rates are a multiplicative factor of the nominal.  There is
> extreme
> > >> skew in our datasets in a number of ways.
> > >>
> > >> We don't have time to work with every new internal/external client to
> > tune
> > >> their feeds. They need to be able to take one of the many kafka
> clients
> > and
> > >> go off to the races.
> > >>
> > >> Being able to retrieve client metrics would be invaluable here as it's
> > hard
> > >> and time consuming to communicate out of the enterprise walls.
> > >>
> > >> This KIP is important to us to expand the use of our datasets
> internally
> > >> and outside the borders of the enterprise. Our clients like the
> > performance
> > >> and data safeties related to the kafka connection. The observability
> has
> > >> been a problem...
> > >>
> > >> Jonathan Rivers
> > >> jrivers...@gmail.com
> > >>
> > >>
> > >>
> > >>
> > >> On Mon, Oct 18, 2021 at 11:56 PM Ryanne Dolan <ryannedo...@gmail.com>
> > >> wrote:
> > >>
> > >>> -1
> > >>>
> > >>> Ryanne
> > >>>
> > >>> On Mon, Oct 18, 2021, 4:30 AM Magnus Edenhill <mag...@edenhill.se>
> > >> wrote:
> > >>>
> > >>>> Hi all,
> > >>>>
> > >>>> I'd like to start a vote on KIP-714.
> > >>>> https://cwiki.apache.org/confluence/x/2xRRCg
> > >>>>
> > >>>> Discussion thread:
> > >>>> https://www.mail-archive.com/dev@kafka.apache.org/msg119000.html
> > >>>>
> > >>>> Thanks,
> > >>>> Magnus
> > >>>>
> > >>>
> > >>
> >
> >
>

Reply via email to