►
From YouTube: Fluent Community Meeting March 24, 2022
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
Okay,
so
yeah,
hey
everyone
thanks
for
for
joining.
This
is
one
of
our
kind
of
second
march
45
minute
fluent
community
meetings.
We
got
a
pretty
good
agenda
here.
I
have
a
couple
topics
that
I
didn't
put
on
the
agenda,
but
are
more
just
logistic,
wise.
A
You
know
I've
seen
a
lot
of
folks
do
community
meetings
through
meetup.com
and
I
think
I'll
probably
start
moving
some
of
the
affluent
meetings
to
to
that.
I
think
it
just
has
a
nice
system
to
remind
folks
and
easy
sign
up
and
and
what
not,
of
course,
not
necessary-
we'll
still
keep
this
google
doc
agenda.
So
if
you
want
to
be
anonymous-
and
you
know
just
drop
in
via
zoom-
that's
perfectly
fine,
no
need
for
for
meetup,
but
for
those
who
do
want
a
little
bit
more
kind
of
organization
around
it.
A
I
think
that
will
that
will
be
great
yeah.
I
think
that,
besides
that
we
we
are
looking
at
fluent
con
coming
up
in
may
so
we're
we
have
some
some
sessions
already.
I
think
the
agenda
will
come
out
here
next
week,
so
that'll
be
really
exciting
and
you
know
folks
will
be
able
to
to
really
start
start
to
see.
What's
going
on
and
and
for
folks
who
are
in
europe,
it'll
be
a
good
chance
to
meet
up
in
person.
A
If,
if
you
can't
and
yeah,
I
think
you
know
besides
flynn
con
we'll
have
a
couple
of
sessions
at
kubecon
itself
a
lot
of
discussions
about
like.
What's
next
for
flynn,
pitfall
and
d,
you
know
we
we've
been
really
focusing
on
metrics
and
and
more
open,
telemetry
style
integrations
and
we're
really
interested
in
the
community
feedback
to
say:
hey.
A
What's
up,
you
know,
what's
what's
really
useful
there
for
for
for
users,
so
there's
a
great
forum
for
it,
but
you
know
also
fluentcon
can
can
help
us
get
some
more
feedback.
A
little
bit
rapid,
more.
B
A
B
Yeah,
I
didn't
have
anything
too
too
massive.
I
just
want
to
bring
up
a
few
things.
Obviously,
the
con
schedule's
out.
B
Yeah
so
a
couple
of
issues,
there's
quite
a
few
stale
branches,
so
just
trying
to
publicize
that
to
get
people
to
clean
up
any
that
are
theirs
before
we
go
in
and
smash
them,
so
yeah,
there's
quite
a
few
there
that
are
like
merged
from
pr's
or
just
sat
dead
for
multiple
years.
So,
if
anyone
can,
if
anyone's
got
stuff,
that's
sat
there
that
they
don't
want
or
needs
merging,
probably
best
to
do
it
yeah,
the
other
one
is
the
regular
release
cadence.
B
A
One
quick
thing
for
the
branch
cleanup:
I
I
think
this
is
great,
especially
like
we
should
absolutely
clean
up
the
ones
that
are
already
merged.
Yeah
yeah,
the
one
one
thought,
though,
was
like
the
ones
that
are
kind
of
like
dynamic
stream
processing
where
it's
it's
like
a
test.
Pr,
nothing,
nothing
done
there
like.
We
can
keep
those
things
around
right
and
like
it's
not.
A
B
Most
ones,
I
think,
should
be
a
no-brainer
to
like
just
delete
those,
but
also
give
people
notice
because
maybe
emerge
but
they've
put
more
changes
on
that.
I
don't
know
be
a
bit
funny
and
there
might
just
be
some
that
are
sat
around
that
are
just
you
know.
There's
like
a
big
query
like
one
on
there.
Do
they
need
pull
requests?
Are
they
dead?
You
know
kind
of?
Is
it
something
that
maybe
there
was
a
pull
request
and
it
got
closed
or
stuffed
like
that?
Yeah.
A
Yeah,
so
anything
below
1.7
merged
delete,
no
problem.
I
know
there's
like
some
question
of
like:
did
we
backport
some,
so
it
might
be
merged
in
in
1.9,
but
it
might
be
merged
in
1.8.
So
we
probably
just
just
like
a
sanity
check
on
some
of
them.
B
If
we
can
close
the
ones
that
emerge,
that's
probably
a
good
good
first
step
and
probably
need
to
enable
that
auto
closing
when
pr's
emerged
as
well.
Although
then
the
people
want
that,
if
they're
doing
back
courting
but
yeah,
it's
a
bit
funny
to
back
from
you
you'd
end
up
having
to
rebase
and
it
gets
a
bit
yeah
messy
yeah
and
then
the
the
regular
release.
So
one
of
my
frustrations
before
was
like:
what's
the
release
process,
how
often
does
it
go
on?
B
Let's
make
sure
it's
automated,
so
so
what
we've?
What
proposing
here
and
it's
sort
of
partially
implemented
now
is
nightly
builds,
so
we've
got
those
for
1.8
and
master,
and
so
there,
if
you
look
on
the
github
repo
you've
got
unstable
releases
which
are
nightly
builds
of
all
supported
packages,
windows
as
well,
and
the
containers,
and
then
those
feed
in
the
the
plan
is
so
for
1.9.
We
already
have
an
automation
workflow
for
staging
and
release,
and
the
plan
is
to
took
unstable
up
interstate
that
will
do
unstable.
B
Unstable
may
fail
tests,
it's
just
a
nightly
build
if
it
doesn't
fail
tests,
it
goes
into
staging
and
then
we
always
have
something
in
staging.
That
should
be
green,
that
we
can
release.
B
So
the
plan
is
to
like
automate
that
so
like
every
two
weeks
or
whatever
we
decide,
we
just
take,
what's
in
staging,
make
it
into
a
release
and
obviously
there's
some
stuff
to
deal
with
like
making
sure
semantic.
Versioning
is
maintained
and
stuff
like
that.
But
those
are
problems
we
can.
We
can
solve,
but
yeah,
that's
that's.
The
plan
just
wanted
to
get
make
sure
people
were
were
aware,
but
yeah
it's
like.
So
you
push
your
merge
in.
You
don't
have
to
go.
When
is
it
going
to
come
out?
B
To
like,
we
do
do
some
integration,
we
do
a
load
of
integration,
testing
for
pr's,
but
there's
not
so
much
performance
and
kind
of
resilience,
testing
and
the
plan
is
to
hang
those
off
staging.
So
we
do
like
we
get.
You
know
unstable,
we'll
get
some
level
of
testing
to
say
yeah.
This
is
this
is
okay
to
release,
but
then
maybe
we
want
to
hang
off
performance
and
resilience
testing.
That's
a
bit
more
like
resource
intensive!
B
You
don't
want
to
do
it
every
single
push
or
commit,
or
whatever
you
just
want
to
do
it.
Maybe
when
you've
got
a
nice,
stable
baseline,
and
so
that's
that's,
where
we're
going
to
going
to
hang
those
off
and
yeah
just
just
make
it
all
automated.
So
you
know
nightlys
go
into
staging
when
they're,
okay,
staging,
sits
there
and
then
gets
updated
with
okay,
nightlys
and
then
staging
is
basically
always
always
releasable
and
and
we
can
just
push
the
button
and
it
goes
out
the
door.
B
So
that's
that's
the
plan
so
yeah.
If
you
can
see
the
unstable
ones,
there's
a
few
things.
I
want
to
do
on
that
as
well.
There's
a
few
few
changes,
so
quite
a
lot
of
stuff's
already
in
there
there
were
some
big
changes
initially
to
deal
with
building
from
source
for
packages
and
containers,
because
there
was
lots
of
reliance
on
people
creating
tags
first
and
then
building
those
tags
which
is
not
not
what
we
want
for
nightly.
B
There's
a
few
other
bits
and
pieces.
Yeah
we've
got
the
git
commits
in
the
version
output
now,
which
is
quite
useful
because
we
had
a
an
issue
where
we
accidentally
released
1813,
I
think,
which
was
built
on
one
eight
twelve
source.
So
we
should
pick
up
those
kind
of
things
quite
easily
now
yeah,
so
it's
all
in
there
and
maybe,
if
you
go
to
the
releases
bit
on
fluent
bit.
B
So
if
you
go
to
yeah,
just
go
to
the
main
repo
and
jump
to
the
releases
section,
so
it
won't
show
up
in
there
in
the
like
the
sidebar,
because
it's
not
a
official
release
but
yeah.
You
can
see
what's
in.
What's
in
that
quite
a
lot
of
changes
by
me,
but
it
kind
of
gives
you
the
change
log
from
from
the
last
last
release,
and
then
we've
got
a
big
set
of
packages
for
all
the.
So
if
we
open
the
assets
there,
so
that's
all
the
packages.
B
So
I
was
uploading
individual
packages
for
like
each
os
and
architecture,
but
the
github.
Well,
it's
a
bit
flaky
now
quite
a
lot,
but
you
know
a
month
or
two
ago
when
I
was
testing
all
this.
It's
better
to
upload
one
big
file
than
it
is
to
upload
lots
of
small
files,
because
I
was
getting
occasional
failures
and
then
the
whole
release
fails.
So
it's
a
bit
of
a
pain,
so
we
got
that
so
yeah.
I
just.
B
B
So
it's
good
for
me
because
you
know
when
I
have
my
coffee
come
in,
I
can
check
if
it's
worked
and
then
1.8
builds
six
o'clock,
utc
pm
so
about
12
hours
apart
and
there's
a
1.9
build
set
up,
but
we
don't
have
a
branch
for
it,
so
it
just
fails
at
12
o'clock,
so
yeah.
B
If
I
did
a
build
overnight,
utc
time
like
2
a.m,
whatever
a
lot
of
the
repos
fail,
particularly
centos
ones,
it
just
fails
to
download
dependencies.
So
I
think
there's
some
flakiness
overnight
with
maintenance
windows
and
stuff
like
that,
so
a
bit
of
trial
and
error,
but
six
six
a.m
seems
to
be
the
best
option
for
for
doing,
builds
and
yeah
the
last
one.
So
1.9
was
out
a
while
ago.
1.815
is
out
today
I've
published
all
the
packages.
Just
so
people
are
aware.
We
changed
the
gpg
keys.
B
There
was
a
few
issues
with
them.
There
was
like
eduardo's,
personal
keys
and
things
like
that,
so
they're
a
proper
like
fluent
bit.
I
o
release
key
now,
but
it's
flagged
in
the
documentation,
but
there
are
a
few
questions
on
slack
and
stuff
like
that.
So
people
just
need
to
be
aware
that
you
might
see
some
if
you.
A
Let's
do
a
tweet
and
then
maybe
maybe
we
could
do
a
pinned
issue.
I
think
that
would
be
yeah.
I
mean
it's
in
the
docs
as.
B
Well,
though,
you
can
have
a
look
on
those
as
well,
but
yeah
yeah,
that's
problem
and
because
the
the
main
issue
is
so
all
the
new
stuff.
So
from
one
point,
nine
and
one
eight
fifteen,
it's
all
signed
with
the
new
keys
and
but
obviously
the
legacy
stuff
that
hasn't
been
updated,
hasn't
been.
B
There's
touched
little
bit
of
stuff
there.
So
yeah,
that's
that's
what
I
had.
There
was
one
other
thing,
but
I
forgot
what
it
was
doing.
All
that
talking
our
fluent
talks.
You
should
mention.
A
Okay,
yeah,
I
could
give
a
quick,
quick
overview.
So
for
folks
we
do
it's
more
of
a
calyptia
thing,
so
we
as
as
a
company
do
this
thing
called
fluent
talks
every
friday.
This
friday,
we're
gonna
do
one
on
openshift
and
we
just
you
know,
pat
just
published
a
blog
about
openshift,
getting
logged,
sending
it
to
splunk,
elasticsearch
and
grafana
so
yeah.
We
welcome
folks
from
the
community
to
join
this
district
audience
as
well
and
ask.
B
B
Something
that's
come
up
recently,
so
I'm
doing
fl,
I'm
doing
windows
builds
nightly.
We've
obviously
got
the
app
vario
ones
for
releases
containers
who's
using
them
because
they're
massive,
like
the
windows
containers,
we
build.
B
I've
stopped
building
it
lightly
because
they're
six
gig
and
they
just
take
like
an
hour
and
a
half
to
build
it's
just
terrible.
So
it's
whether
anyone
actually
needs
them.
I'd
like
to
add
mac
os
builds
as
well
for
the
packages.
It
should
be.
Nice.
A
Mac,
we
might
be
able
to
add
later
in
their
release
cycle,
but
yeah
I've
started
to
see,
see
that
pick
up
a
little
bit
as
well.
A
D
An
operator
should
have
just
yeah,
just
one
quick
question
on
windows:
how
popular
is
the
usage
of
the
down
port
image
port
for
windows
from
data
and
windows?
We
don't
have
a
windows.
A
D
So
what
is
our?
What
is
your
thinking
about?
Moving
towards
get
it's
assuming
darker
has
it,
but
what's
our
plan
to
increase
the
the
scope
onto
windows
because
we
have
heard
from
awsi,
we
have
heard
the
usage
and
ask
customers
from
on
windows
as
well.
Just
won't
get
your
scene
yeah.
You.
A
B
I'm
saying
I
opened
the
discussion
on
it
like
who's
using
it.
The
one
we've
got
is
six
gigs,
so
it's
like
really
big
and
takes
a
really
long
time
to
building
github
actions
and
then
there's
there's
the
complexity
of
windows
containers
and
they
have
some
alignment
with
the
host
as
well.
So
your
windows
version
and
your
container
based
version
have
to
be
close
enough
that
they
can
talk
to
each
other.
So
there's
a
few
questions
there
is
like.
If
we
do
a
windows
container,
what
should
we
do.
C
B
B
D
B
A
Yeah,
so
we,
this
is
some
background.
We're
allotted
some
github
runners
as
part
of
being
oss,
but
yeah
generally,
like
you
have
to
share
those
resources
across
all
our
builds.
So
if
you're
doing
mac
and
linux
and
like
different
distributions
of
linux,
then
you
will
occupy
most
of
the
time
doing
like
this
windows
build.
So
it's
not
something
we
could
probably
do
nightly
for
sure
unless
it's
a
hint
on
hints
sponsored
by
by
someone
like
aws
but
yeah.
B
So
for
me
I
would
like
to
do
it,
but
it
just
seems
like
at
the
moment,
like
the
yeah,
I
think
there's
so
I
raise
it
in
here
like
we
either
do
it
and
we
make
it
good
or
we
don't
have
the
docker
files
in
because
there's
no
point
having
docker
files
in
there
that
we
don't
build
because
they
won't,
you
know,
they'll
be
broken
and
you
know
do
they
work
yeah?
What's
the
point
you
know,
so
we
need
to
like
decide
what
we
want
in
there.
So
that
that's
my
only
that's.
B
A
B
A
B
I
think,
as
I
say,
I
think
we
should
have
them
but
they're,
just
not
in
a
good
state
at
the
moment
and
and
the
question
is
they're
not
as
straightforward
as
linux
containers
because
of
that
kind
of
coupling
the
host.
So
it's
a
good.
The
question
is
like
we
can't
support
like
10
different
variants.
We
should
just
say
you
know
these
are
these?
Are
the
versions
we're
supporting
and
if
you
need
a
special
windows
flavor
for
various
special
reasons?
Well,
just
fork
it
and
do
it,
but
yeah.
A
Hey
awesome
anything
else
from
anyone.
A
Okay,
I
think
we
can
get
folks
time
back.
There's
a
nice
short
one
said
we'll
talk
next
time,
which
will
be,
I
think,
we'll
have
two
more
meetings
before
fluentcon,
so
these
will
be
usually.
A
One
like
the
other
time
zone
yeah.
I
think
I
think,
instead
of
doing
it
every
other
week
doing
eu,
I
I
would
pre,
I
would
suggest
we
do
it
once
every
four.
So
we
do
so
once
every
so
three
in
us
time
and
then
one
in
eu
ap
apj
time.
So
it's
like
every
four
that
time
zone.
Just
because
I
I
mean
this
one
isn't
a
great
example
either,
but
it's
like
it
seemed
like
the
attendance
rock
down
with
with
the
different
times,
though
yeah.
A
A
A
All
right:
well,
I
can
I
could
take
over
if
we
need
well,
we
could
get
someone,
someone
else
and
then
you
to
host
it
yeah.
A
Well,
thanks
for
joining
zhang
kui,
but
we're
we're
actually
wrapping
up
anything.
Last
minute,
though,
we're
happy,
we
have
some
time.
Okay,.
D
A
D
Chases
filter
yeah,
so
people
can
have
some
have
visibility
and
what
we
can
do
and
also
feedback
right.