►
From YouTube: Fluent Community Meeting July 29th 2021
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Perfect,
okay.
Welcome
to
the
second
fluent
community
meeting.
We
had
a
meeting
last
week
to
talk
a
little
bit
specifically
on
the
fluent
operator
project
and
bringing
that
into
the
fluent
ecosystem.
So
I
think
there's
there's
a
couple
of
work
items
that
that
are
over
there.
I
think
it
might
be
noted
in
this
yep
in
this
meeting.
We
have
a
couple
of
agenda
items
already
here,
so
maybe
we
can
just
start
with
that.
C
Briefly
and
last
time
as
well,
it's
come
up
a
few
times.
Certainly
for
me,
there's
a
couple
of
a
couple
of
issues
that
I've
tried
to
capture
there.
You
know
if,
if
we
do
a
fix
which
release
does
it
go
in?
It
can
be
quite
hard
to
figure
out
just
looking
at
github,
where
it's
gone
in
and
also
kind
of
the
longer
term
roadmap.
So
there's
stuff
coming
in
like
1.8,
I
think,
there's
stuff
today.
C
In
fact,
while
they're,
like
1.83,
is
doing
some
system
d
changes
that
someone
asked
about
as
well.
So
it's
just
those
kind
of
things
you
know
people
are.
People
may
already
have
a
bit
in
production
or
using
it
and
there's
some
features.
You
guys
are
adding
but
they're
looking
at
evaluating
some
other
way
of
doing
that
or
stuff
like
that,
and
it
would
be
quite
useful
to
know
what's
coming
up.
C
So
those
are
the
two
main
questions
I
was
trying
to
try
to
solve
and
it's
come
up
a
few
times
in
slack
as
well
and
stuff
like
that.
You
know,
when
is
this
fixing
which
release
and
I've
had
to
look
a
few
times,
and
it's
just
a
bit
of
a
nightmare
to
figure
out
with
the
cherry
picking,
so
I
tried
to
capture
some
thoughts
and
and
some
of
the
stuff
that
like
eduardo,
has
already
done.
C
So
I
tried
to
capture
that
I
think
the
first
bit
was
just
kind
of
documented
the
release
process
a
bit
because
I
don't
know
what
it
is.
I'm
you
know.
Obviously
you
guys
do,
but
from
externally,
as
a
user
of
it,
it's
like
well
when
a
release
is
happening
and
what's
going
to
be
in
them,
would
be
quite
be
quite
useful,
just
just
to
know
that
this
is
coming
into
this
release
and
things
like
is
there
options
to
pull
in?
C
You
know
like
a
release
branch
or
something
before
it's
released,
so
I've
got
a
load
of
integration
tests
that
I
can
run.
You
know
when
I
build
it
from
source
and
stuff
like
that.
So
it'd
be
quite
useful
to
say:
oh
we're
about
to
release
this
one.
You
know,
or
it's
a
beta
or
something
like
that.
You
know
try
and
get
a
bit
more
coverage
of
it
then
as
well
so
eduardo
knocked
out
that
wiki
page.
C
I
think
you
asked
me
didn't
you
and
I
just
said:
let's
put
it
on
the
github
wiki,
but
is
that
the
right
place
to
put
it
for
people?
I
figured
you
know
you're
looking
at
the
source
code,
you
got
the
wiki
there
as
well
it'd
be
quite
useful.
I
think
all
the
contribution
stuff
is
all
in
in
the
repo
as
well.
So
it
makes
sense.
I
mean
there's
the
docs
as
well.
Maybe
end
users
are
consuming
it
from
fluent
bit.
I
o,
maybe
it's
better
to
put
there.
C
So
that's
probably
a
question
for
for
people.
There's
a
few
questions
in
here.
You
know
it's.
It's
just
my
ideas
at
the
moment
so
feel
free
to
to
disagree
or
or
suggest
anything
else
more
than
happy.
To
give
you
a
hand
with
us
eduardo,
I
know
you're,
you
know
quite
busy
doing
doing
the
actual
important
work
of
developing
stuff
and
implementing
things
rather
than
their
documenting
it.
So
I'm
happy
to
do
that.
C
C
It's
just
try
and
answer
those
two
questions.
I
think
like
what
what
what
changes
are
in
a
release
or
which
releases
are
changing
and
what
are
you
doing
sort
of
on
the
roadmap?
C
So
I
had
a
few
ideas
there.
I
don't
I'm
very
mad
as
well.
People
get
a
bit
nervous.
You
put
dates
on
it.
Things
like
that
people
go!
Oh
well!
That's
when
it's
going
to
be
released
now
I
was
just
thinking
more
like
q1,
q2,
q3
kind
of
things,
which
is
what
actually
github's
roadmap
does
as
well,
which
is
quite
convenient.
Obviously
you
have
to
explain
when
q1
is
because
it
might
be
different,
you
might
be
in
january,
it
might
be
in
you
know,
october,
for
some
strange
date
system.
C
So
it's
you
just
have
to
do
that.
But
that's
that's
that's
what
I
was
thinking.
I've
got
a
couple
of
links
there,
so
there's
a
github
roadmap,
which
is
it's
a
bit
busy
to
be
honest,
there's
a
lot
of
it,
but
it's
quite
well
documented
because
they
obviously
have
to
do
lots
of
different
features
for
different
things.
So
it
might
be
worth
having
a
look
at
how
they
do
some
of
their
feature
and
release
branches
and
stuff
like
that,
so
that
documentation's
got
it
goes
through.
C
You
know
the
phases
and
stuff
like
that.
So
I
I
would
say
it's
probably
a
lot
more
than
than
you
potentially
want,
but
it's
probably
complete
and
and
working
there
and
then
they've
got
this
which
is
yeah.
You
can
see
everything,
but
if
you
see
what
I
mean,
it
is
a
bit
like
where's
my
feature
so,
but
if
you
actually
click
on
it,
I
don't
think
it
actually
tells
you
when
yeah
you
can
kind
of
see
where
it
is,
but
I
couldn't
see
a
way
of
oh
no.
C
If
you
can
yeah
so
it
has
got
the
actual
actual
thing.
So
those
kind
of
things
you
know
like
if
we
had
something
like
that
might
be-
might
be
nice
to
have.
But
again,
not
too
much
overhead
on
people
actually
doing
the
work
you
know.
Is
there
a
way
you
can
automate
that?
Can
we
just
tag
stuff
quite
easily
and
yeah?
C
Those
are
my
kind
of
my
kind
of
ideas
and
obviously
microsoft
are
doing
loads
of
work,
and
I
think
that
github
pushed
out
some
new
discussions
or
whatever
they
called
it
now,
and
things
like
that.
So
it's
it's
whether
we
adopt
some
of
that
stuff,
which
they
seem
to
be
pushing
quite
hard,
but
might
not
be
very
good.
C
So
that's
the
gist
of
it.
Do
you
want
to
have
any
comments,
suggestions.
D
Yeah,
I
have
a
couple
of
comments
and,
for
example,
I
I
think
that
okay,
I'm
trying
to
figure
out
what
would
be
the
best
solution,
a
to
share,
what's
coming
up
on
a
specific
release
right,
sometimes
we
have
two
kind
of
contributions
right.
One
of
them
are
kind
of
a
contribution
for
fixes
contributions
for
future
sets
for
new
features
right
that
none
of
the
maintainers
are
aware
about.
D
D
But
the
thing
is
the
following:
here's,
the
problem:
the
prs
are
not
a
problem,
but
when
merging
the
prs
right
personally
because
of
maintenance,
we
are
using
a
rebase
the
rebase
option,
instead
of
merge.
Otherwise,
when
you
get
the
whole
a
git
lock
the
gitlab
for
the
project,
you
just
get
a
bunch
of
merch
commit
without
details
of
about
a.
What
is
the
comment
about
right?
D
That's
why,
when
we
rebase
a
stack
we
get,
which
of
which
interface
a
component
got
modified
and
what
was
the
change
and
it's
a
easy
way
also
to
backboard
those
changes
that
landed
on
master
to
a
stable
release,
for
example
at
the
branch
1.8.
So
I
think
that
there
are
two
things
that
we
have
to
fix.
The
first
one
is
find
a
way.
I
don't
know
if
you
have
actions,
allows
that
or
anything
on
github
like
for
every
comment
that
lands
in
a
pr
get
the
pr
number
on
every
comment.
D
D
That's
one
thing
that
we
need
to
fix.
Secondly,
I
like
the
idea
of
using
labels,
I
think
that
we
have
to
come
up
with
a
structure
of
how
to
use
the
labels.
For
example,
if
I
have
a
pr
that
was,
for
example,
upax
send
a
pr
for
master
right,
because
everything
should
be
for
for
master
first
right
and
something
this
oh,
this
is
a
good
addition,
also
for
1.8
right.
What
kind
of
labels
do
we
use
in
order
to
know
that
hey?
This
must
be
back
ported
to
the
stable
branch
looks
like
rafana
is
using.
D
That
mechanism
looks
like
I
saw
it
some
weeks
ago,
a
but
would
be.
I
would
let
get
more
opinions
and
suggestions
on
that,
but,
at
least
from
cherry
picking,
the
comments
is
what
is
working
from
the
maintenance
perspective,
but
we
need
to
find
the
solution
on
how
to
expose
those
changes
with
pr
number
in
a
in
a
better
way.
A
Got
it
so
we
can
like
automate
some
of
this
away
with
some
github
actions,
and
then
we
can
try
to
label
it.
I
think
the
public
roadmap
idea
is
a
pretty
good
idea.
I
think
the
I'm
trying
to
think
of
how
far
we
could
go
out
like
do.
We
want
to
do
a
one
year
type
roadmap,
and
that
might
be
that
might
be
a
bit
hard
to
be
honest
and
you
could
just
have
yeah
sure,
medium
long
time
exactly
yeah.
I
think
at
least
two
quarters
seems
pretty
reasonable
and
yeah.
A
I
wouldn't
mind
putting
that
together
and
what
we
could
do
is
also
share
it
in
this
community
meeting.
So
at
least
one
of
the
three
community
meetings
every
quarter
is
hey.
This
is
a
review
of
what
the
roadmap
has
and
yeah.
This
is.
This
is
what
the
focus
is
for
for
x
version
and,
of
course,
subject
to
change
right.
Also,
like
hey
we're,
seeing
this
trend
growing
we're
going
to
work
on
that
a
little
bit
more,
but
I
think
that
that
might
help
a
lot
as
well.
A
Also,
it
would
help
because
we'll
be
able
to
see
how
many
people
you
know
can
spend
some
time
doing
certain
things
that
are
in
the
roadmap,
but
we
don't
know
where
they'll
land
right
so
yeah.
I
I
like
the
idea
of
using
the
wiki
and
and
and
creating
like
one
of
these
giant
github
projects
yeah.
I
don't.
I
don't
know
how
to
do
that,
but
I'm
sure.
D
Think
I
think,
for
sure,
yeah
with
the
road
map,
the
thing
that
I
think
that
we
have
to
figure
out
how
to
handle
is
like.
Okay,
for
example,
me
as
eduardo.
I
can
put
in
the
moment
what
I'm
planning
to
do
for
the
project,
but
that
does
not
cover
what
other
people
would
like
to
have
right
right
and
who's
going
to
do
it
right.
D
D
We
have
some
engineers
assigned
it
to
working
on
their
full
time
in
the
project,
so
we
can
put
what
we
are
working
on
on
and
what
our
efforts
right
on
our
areas,
but
that
should
not
be
the
whole
picture
of
the
project
right,
because
also,
we
have
to
coordinate
with
a
invite
amazon
folks
who
are
contributing
google
folks
also,
and
how
to
build
this.
This
road
map
also.
D
I
think
yeah
yeah
we
have
to
we
have
to
make
this
road
map,
but
I
don't
know
how
to
specify
that
this
is
kind
of
flexible
enough
right
that
if
we
decide
someday
to
push
some
future
for
the
next
quarter,
we're
not
going
to
get
a
pushback
from
the
community.
Hey
just
say
you
you're
going
to
do
this
on
this
time,
but
it
doesn't
works
like
that
right.
D
But
I
understand
that
we
should
have
some
organization,
because
the
end
user
also
understands
what
path
is
saying.
It's
like
me
as
an
end
user.
I
want
to
know
what
is
coming
up
right,
yeah
and
that
is
really
important
right,
so
actually
for
this
year.
I
think
that
we
were
pretty
sad
like
we
knew
that
we
wanted
to
jump
into
metric
space
and
then
create
a
different
collector
for
metrics
and
create
prometheus
connectors.
C
I
might,
I
would
prefer
yeah
big
chunkier
things
I
mean
I'd
also
say:
maybe
we
should
just
try
yeah.
We
probably
won't
come
up
with
the
perfect
solution
immediately
and
it
might
be.
We
try
a
few
things
and
they
don't
work
or
that
yeah
there's
a
bit
of
feedback
and
we
iterate
them
as
well,
because
I
know
like
you
guys,
are
presenting
some
of
this
kind
of
information
at
fluentcon,
but
people
may
not
have
the
time
or
go
to
see
it
as
well.
C
A
E
I
agree
with
you
that
too,
where
and
there's
a
perspective
from
an
affluent
community
if
we
were
to
expand
to
newer
like
domain,
for
example
like
metrics
and
then
windows
metrics
or
if
you
had
to
expand
it
to.
E
Let's
say
you
know
even
endpoints,
like
you
know,
ios
android,
I
don't
know
if
you
will
expand
but
a
bigger
picture
where
we're
heading
and
then
I
think,
if
you
have
to
go
deeper
in
specific
domain,
I
think
that's
another
dimension
that
we
might
be
able
to
add
so,
but
I
think
that
way,
people
you
know
the
vector
of
where
we
are
going,
then
that
that
granularity
should
be
kind
of
good
enough
for
people
to
understand
where
we
can
use.
E
A
C
We
could
set
a
bit
of
time.
You
know
five
minutes
for
each
community
meeting
just
to
review
the
road
map
for
the
next
bit.
There's
maybe
people
like.
Oh,
I
really
want
to
see
this,
or
this
is
really
important
to
me.
Those
kind
of
questions
I
did
the
operators
come
in
as
well,
so
that
probably
should
be
on
there,
because
some
kind
of
time
scales
as
well.
A
Right,
yeah,
okay,
so
I
think
from
from
an
action
side,
let's,
let's
use
this
wiki
and
then
maybe
use
this
kind
of
kind
of
the
github
way.
I
like
I
kind
of
like
the
the
project.
Maybe
we
could
have
these
giant
issues
in
at
least
like
in
both
repos
that
represent
hey.
This
is
the
issue
for
fluentd's
road
map,
here's
something
for
fluent
bit
and
here's
who's
who's
like
possibly
behind
it
as
well.
Yeah.
C
Because
I
presume
you
can
filter
yeah,
you
must
be
able
to
film
yeah.
If
you
only
care
about
for
a
bit.
You
could
just
say
just
show
me
the
roadmap
kind
of
discussions,
yeah
and
I
mean
I'm
happy
to
lend
a
hand
as
well.
I
don't
want
to
just
come
up
with
like
I
do.
Oh,
I
think
it'd
be
really
good.
If
you
guys
did
all
this
work.
A
Yeah
and
I'd
be
really
really
awesome
to
collaborate
on
something
like
that.
Yeah
and
I
I
just
I
saw
that
you
carved
out
some
some
time
monday.
So
I'm
like
say:
hey,
let's,
let's
grab.
C
Yeah
I
mean
the
others
yeah,
I'm
not
overly
fussed.
If
you
do
a
github's
approach
or
whatever
the
main
reason
was
we're
on
github
already
they've
invested
some
time
effort
money
into
doing
these
kind
of
things,
so
you
would
hope
that
they
would
be
kind
of
supported
and
kind
of
improving
as
well
rather
than
us,
making
up
another
way
of
doing
it.
Yeah.
A
C
So
if
I
summarize
that
so
I
think
I
think
we've
got
two
there's
the
two
problems.
There's
like
how
do
we
know
what's
in
the
release
and
there's
the
roadmap,
so
the
roadmap,
it
sounds
like
we're
fairly
happy
to
do
kind
of
high
high
level
blocks
of
stuff
using
that
approach
and
then
for
the
what's
in
the
release,
does
obviously
all
the
problems
you've
got
eduardo
with
like
maintaining
it
and
doing
it,
and
we
need
to
focus
on
automation,
I
think,
to
to
try
and
how
do
we
spit
out?
C
D
C
A
Yeah,
I
think
part
of
the
automation
can
also
be
things
that
have
been
merged
to
master
but
have
not
been
tagged
and
released,
and
we
just
have
to
not
like
we
can
like.
I
I
was
looking
at
one
the
other
day
I
was
like.
Oh,
we
should
get
this
out
there,
which
was
like
apache
skywalking
plug-in,
and
I
was
like,
oh
okay,
so
this
thing
has
been
merged,
but
it
hasn't
been
selected
for
a
release.
A
We,
maybe
we
can
label
it
with
like
needs,
a
release,
tag
or
something,
and
then
we
can
review
that
on
an
ongoing
center.
Like
oh
shoot,
okay,
why
is
this
not
release
tag?
Okay,
it's
using
like
something
else
or
hey.
There
was
a
there's
something
waiting
and
we
don't
have
necessarily
like
okay,
hey
the
maintenance
of
this
is
actually
the
part
that
we're
worried
about
is
someone
gonna
sign
up
to.
A
You
know,
do
the
testing
for
this,
but
I
think
that
automation
can
help
us
make
the
decisions
for
like
what
label
it
goes
in
and
that
way
it's
not
too
much
of
a
burden
on
like
every
person
must
put
a
label.
We
can
continue
doing
what
we're
doing
well.
Now
we
just
have
a
new
checklist.
We
can
check
every
month.
D
Actually
that
that
needs
to
be
manual,
I
think
the
labels
because,
for
example,
yeah
so
talking
at
this
example
that
apache
arrow
right,
I
saw
the
pr
it
was
reviewed,
but
my
concern
was
from
my
entire
perspective
and
packaging.
The
release
hey.
If
I
ship
this
I'm
going
to
miss
some
package
dependencies
on
the
rpms
or
the
deviants
yeah,
it
was
like
okay,
I'm
going
to
break
something.
If
I
add
it
now
yeah,
so
I
prefer
to
hold
it
back
right.
D
But
if
I
get
another
pr
that,
for
example,
leonardo
nicole,
is
doing
some
dns
fixes
networking
staff
which
fixes
should
be
you
know,
for
the
stable
version
and
the
developer
version.
I
would
like
to
have
a
way
to
say:
okay,
this
cpr,
I
should
apply
a
label
because
this
must
be
backported,
so
nobody
forgets
about
it.
Yeah
and
that's
model
right,
but
once
it's
back
quoted,
we
have
to
have
another
level
say
yeah.
This
is
ready
and
before
the
release,
maybe
we
can
check
out
hey.
D
Let's
take
a
look
at
the
1.8
branch
of
the
pr,
for
one
today
is
everything
aligning
was
everything
merged
yeah?
Are
we
missing
something
or
not?
So
I
think
that
is
mostly
a
manual
workflow,
a
procedure
that
we
have
to
describe.
I
don't
think
that
is
too
complex.
Is
you
know
we
have
to
come
up
with
a
solution.
Yeah.
A
A
Part
of
the
suggestion
was
more:
we
just
see
what
prs
there
are
like
today
that
okay,
have
it
been
they're
immersed
in
master
but
haven't
been
tagged
or
released.
So
that
way
we
can
like
okay,
that
one
of
them
is
a
dns
merge.
Okay,
we
should
that
should
be
backwards.
That
will
be
true
and
then
going
forward
yeah.
I
think
I
think
you're
right.
Maybe
it's
just
that
hey
throw
on
a
label
where
we
need
this
to
hit.
D
Yeah
and
that
we
have
maintenance,
because
also
imagine
that
I
don't
know
we
have
a
couple
of
people
has
a
right
access
to
the
repo
right
and
imagine
that
yeah
imagine
I
would
be
in
vacation
or
wesley
will
be
out,
but
somebody
said
yeah.
I
have
right
access.
Oh,
let
me
take
a
look
at
which
prs
must
be
merged
back
into
one
today.
D
F
Yeah
I'm
curious
about
the
kafka
as
an
input
which
I
heard
rumors
about
some
months
ago.
I'm
very
much
interested
because
I
want
to
advocate
for
my
favorite
tool
float
bit.
It
would
be
easier
to
squeeze
it
in
a
whole
bunch
of
little
niches
if
we
can
get
it
going
as
an
input
and
an
output
and
the
full
the
full
pipeline
coolness
all
that
stuff.
D
D
Yeah,
actually,
nothing
exists
right
now
so
yeah,
so
my
suggestion
would
be
like
okay,
if
you're
going
to
integrate
the
kafka
input.
I
know
that
it's
a
high
demand
part
just
move
move.
I
would
say
step
one
move:
a
are
the
article
memory
to
the
main
library
dependencies.
Oh,
I
see
what
you're
thinking
so.
F
A
Yeah,
if
we
could
have
it
in
kafka,
plug
it,
I
know
it's
nick.
I
would
cheer.
I
would
cheer
yeah
yeah.
I
would
use
it
yeah
yeah.
I
I
think
yeah,
I'm
linkedin
kafka,
you
know
have
the
you
did
a
lot
of
the
other
kafka,
but
it'd
be
awesome
and
I
think
we
could
help
with
some
integration
tests,
which
would.
F
A
Yeah
we
should,
we
should
have
like
plug-in
overview
sessions,
how
to
build
your
first
flipbit
plugin.
I
think
we
we
slightly
mentioned
it
earlier,
but
one
thing
on
the
roadmap
for
us,
it's
like
webassembly
plugins,
and
that
is
a
way
for
hey.
If
you
don't
want
to
write
it
in
c,
we
would
we
could
accept
plugins
written
in
whatever
language
rust,
javascript,
whatever
can
compile
the
webassembly,
and
then
you
still
get
the
good
performance.
A
C
C
A
Yeah,
okay,
we'll
keep
it
we'll,
keep
it
45.
Then
yeah
I'll
update
that
for
the
next
one.
F
I
see
you've
got
the
cursor
on
the
iron
kafka
line,
but
you
haven't
typed
anything.
I
guess
that's
accurate,
I'm
going
to
look
into
it
and
probably
take
action,
but
it
hasn't
got
no
official
company
support
in
my
side.
So
I'll
do
it.
When,
when
I
can
and
when
I
want
to
okay.
D
D
A
B
Then
yeah,
okay,.