►
From YouTube: 2021-11-03 meeting
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
A
E
A
E
F
Yep,
cool,
wonderful,
all
right,
so
I
guess
the
first
item
is
actually
mine,
so
flaky
tests
we've
had
a
good
number
of
like
tests
during
the
past
week,
and
I
was
thinking
you
know.
What
can
we
do
to
try
to
address
that?
I
guess
the
first
question
is:
is
it
a
real
problem
that
needs
to
be
addressed
in
a
more
generic
way,
or
are
we
happy
with
the
way
that
we
are
handling
that
right
now?
F
F
So
one
way
that
I
could
think
of
is
you
know,
being
radical
and
disabling
the
component.
That
is
failing,
of
course,
that
only
works
for
for
failures
that
are
happening
on
specific
components,
not
general
faders.
I
think
we
were
having
like
the
the
the
cold
ql
a
failure
happening
and
that
you
know
is
a
general
failure.
Load
tests
are
also
something
that
would
consider
general,
but
we've
also
had
problems
like
with
the
prometheus
receiver.
F
I
think-
and
that
would
be
one
where
I
would
consider
disabling
the
component
until
we
have
a
a
fix
here-
and
I
guess
my
motivation
for
this
one
was:
there
was
a
test
failure
on
a
component
that
had
no
owner
back
then,
so
you
know
what
what
should
we
do
with
that?
There's,
no
one
for
us
to
ping,
and
so
should
we
just
disable
the
component
on
that
case
so
yeah,
I
guess
yeah.
E
C
E
C
F
Well,
it
tests
at
least
unit
tests.
They
should
pass
100
of
the
time
right,
so
if
they
fail
one
percent
of
the
time
there's
a
flucky
test
if
a
test,
if
a
unit
test
is
not
passing
all
of
the
time,
then
it's
a
bad
test
either
the
test
should
be
removed
or
rewritten
or
in
a
trusted
case
like
this
one
here,
like
disable,
the
component
altogether,.
C
F
Yeah,
I
I
don't
know
for
the
sake
of
simplicity,
I
would
say
that
whatever
we
run
as
part
of
the
unit
test,
unit
test
target
is
considered
a
unit
test
for
us
and
it
should
work
all
of
the
time
if,
if
the
code
under
test
cannot
be,
you
know
executed
with
100
success
all
the
time,
then
the
test
should
have
a
mechanism
to
retry,
or
you
know
it
should
be
emitted
into
the
test.
F
E
C
I
I'm
just
saying:
do
we
have?
I
guess
I
thought
that
go
test,
which
was
the
command
that
we
ran,
ran
a
mix
of
these
things.
I
agree
that
there
are
two
different
kinds
of
things
going
on
so,
if
I
think,
if
maybe
if
everyone
is
already
clear
that
there
is
a
there
is
a
way
to
distinguish
between
them
or
that
we
can
make
it
so
through
policy,
I'm
good
with
that.
B
I
guess
this
one
one
thought
here
is
that
we,
even
if
we
did
move
unit
tests
and
integration
tests
to
be
completely
separate,
like
I
think,
flakiness
and
integration
tests,
would
be
just
as
bad
as
flakiness
and
unit
tests.
As
far
as
we're
concerned
so
yeah,
I
agree
there
might
be
separate
issues,
but
I
also
don't
want
to
move
the
discussion
in
the
wrong
direction
here.
F
All
right,
so
do
we
have
an
extra
item
for
this
one
here?
Do
we
have
a
a
conclusion
agreement
on
whether
we
want
to
have
an
sla
or
something
like
that.
F
It's
not,
it
should
not
be
your
your
concern.
I
mean
you
should
of
course
ping
the
maintainers.
If
we
are
not
being
responsive,
saying
you
know,
this
test
is
failing,
is
not
part
of
ipr.
F
You
know
go
after
which
pr
introduced
the
component
and
go
being
the
person
who
opened
the
pr
now
in
none
of
those
two
cases
for
this
past
week,
people
responded
right.
So
again,
it's
not
a
fault
of
yours,
as,
as
you
know,
the
person
who
has
been
affected
by
that
that
that
flatness,
but
it's
something
for
us
maintainers
to
solve,
and
we
solved
that
by
you
know:
pinging
people
we're
fixing
ourselves
and
things
like
that.
C
C
A
F
Yeah,
so
I
wouldn't
say
you
have
to
ping
on
the
slack,
so
you
can
ping
on
on
the
issue
itself,
so
you
can
ping
like
the
group
containers
or
you
can
choose
one
one
material
specifically
and
we
would
look
into
you
know
who
owns
that
and
who
should
fix
that.
F
But
I
guess
the
main
point
here
for
this,
for
this
item
to
be
discussed
is
what
should
be
then
the
btsla-
and
I
would
say
you
know
if
nobody
responds
so
being
first
on
whenever
you
open
the
issue
so
you're
assigned
to
the
component
owner.
If
the
person
doesn't
respond
in
a
couple
of
days,
then
ping
again
and
if
after
a
week
and
there's
no
response,
I
don't
know
what
to
do.
F
You
know,
should
we
just
disable
after
one
week
or
I
think
it's
true
drastic,
because
if
I'm
on
pto
it
took
me
for
more
than
a
week-
and
I
wouldn't
want
to
come
back
from
my
pto
and
just
have
the
component
disabled.
But
again
I
don't
want
to
be
on
future
and
people
be
blocked.
Because
of
me.
H
F
No
yeah,
so
I
would
disable
the
test
that
is
failing,
plus
disabling
the
component,
because
if
there
is
a
test
fader,
then
it's
the
code
that
it
is
testing
it
is
also
faulty
potentially,
so
I
don't
know
I
mean,
should
we
disable
from
from
the
four
components
I
don't
know
I
mean
doing.
That
is
even
more
drastic
than
what
I
had
in
mind.
F
Yeah
and
I
guess
the
point
for
disabling
the
actual
component
is
people
will
work
to
get
the
component
back
and
it
can
only
get
back
whenever
it's.
You
know
it's.
If
of
good
quality,
again
yeah
I,
and
if
there's
a
release
in
between
then
you
know,
then
there
is
a.
There
is
a
huge
problem,
because
then
we
are
introducing
a
breaking
change
to
users
who
have
nothing
to
do
with
them
with
the
problem.
H
E
E
F
So
how
about
we
we
try,
we
keep
trying
to
ping
the
person,
for
I
don't
know
a
month
and
after
one
month
with
no
response,
we
we
just
disable
the
component.
E
We
don't
have
to
ping
only
that
person.
We
should
ask
everyone.
I
think
maybe
maybe
another
option
is
present,
all
the
components
that
don't
have
owners
in
this
meeting
jurassic.
So
let's
say
you
ping
for
a
week
and
then
next
sig
meeting,
we
present
all
the
components
that
don't
have
owners.
Maybe
people
from
here
are
willing
to
maintain
that
and
and
resolve
all
these
issues.
I
mean
an
open
source
project.
We
don't
have
to
have
only
that
person.
F
All
right,
okay,
so
that
that's
good
enough
for
me-
and
I
think
the
potential
of
you
know
having
the
test
fixed
after
a
couple
of
sig
meetings
is
great,
so
we
don't
have
to
think
about
what
next,
unless
we
actually
have.
You
know
bigger
problems,
so
I
think
I'm
I'm
satisfied
with
the
solution.
D
Yeah,
it's
supports
more
compression
method
for
computer
pc.
I
posted
on
follow-up
issue
for
it
and
odom
replies.
I
quickly
checked
through
aws
sdk,
google
and
they
use
several
compression
methods
for
http.
Gzip
is
the
most
widely
used.
It
shows
100
results
in
43
files
and
then
snappy,
who
is
the
next
and
eligible
cstd?
D
They
are
less
lesser
used
than
the
others.
The
std
is
no
not
this
one.
You
can
see
the
follow-up
issue
that
I've
linked.
D
Yeah
I,
when,
when
I
researched
for
about
aws
sdk
for
go,
I
didn't
look
it
up
from
http
compression
methods,
since
this
issue
is
only
about
grpc.
So.
E
Yeah,
so
so
I
have
a
couple
of
things
here
too.
I
I
understand
that
they
are
separate,
but
we
will
use
the
same
code
base
for
the
snappy
or
for
for
zstd
or
for
for
others,
and
I
don't
want
to
end
up
using
snappy
from
google
for
grpc
and
snappy
from
others
for
for
stuff.
So
so
I
think
we
have
to
be.
We
have
to
have
a
consistent
story
and
pick
the
right
dependencies
for
us,
because
if
we
have
a
problem
with
snappy,
we
will
have
to
to
to
solve
it.
E
E
So,
that's
why
I
think
yes,
indeed,
they
may
be
different
issues,
but
I
think
in
general
there
is
a
set
of
compo
of
compressions
that
are
mostly
used
across
any
transport.
Doesn't
matter
if
it's
thrift,
grpc
http,
clean
hdp
or
other
protocol
it
it's
still,
there
are
like
five
or
six
compressions
gzip.
Everyone
knows
he's
the
the
most
used
but
yeah.
I
I
see
snappy
being
very
used.
You
pointed
that
aws
using
snappy
in
in
in,
do
you
know
what
dependency
or
snappy
do
they
use?
E
E
E
So
if
you
look
at
the
tags,
it's
super
early
and
I
that's
why
I'm
asked
which,
which
exactly
dependency
do
you
use,
but
it
has
lots
of
dependencies.
This
yeah.
D
E
D
Yeah,
it's
being
maintained
from
personal
contributor,
but
it's
widely
used
yeah.
It's
super.
E
Used
so
let's
use
the
zstd
from
there
then
lz4
is
anyone
using
lg4.
D
Yeah
it's
the
same
as
just
td,
but
I
think
it
also
pretty
much
well
maintained
and.
H
I
believe
honeycomb
uses
lz4
for
some
things,
but
I
don't
know
if
that's
internally
or
if
that's
external,
facing.
E
E
I
think
it's
in
insight.
I
think.
F
F
F
I
E
But
v4
is
not
used,
is
v3
or
v2
used,
so
it's
54,
it's
like
the
the
the
one
that
we
want
to
bring
is
actually
v2
into
our
stuff.
So
I'm
worried
a
bit
about
bringing
a
super
old
one
that
will
not
be
maintained
because
the
the
grpc
thing
that
that
we
have
in
this
pr,
the
one
that
gives
us
the
utilities
for
grpc,
depends
on
version
two.
H
E
E
H
Yeah
that
may
also
be
an
option.
I
wouldn't
want
to
ask
liz
why
they
they
held
off
like
if
that's
an
internal
breaking
change
to
honeycomb,
that's
not
going
to
affect
us
great,
then.
Perhaps
we
should
jump
straight
to
v4.
If
it's
something
that
might
break
us
or
have
problems
or
an
interface
between
us
and
honeycomb,
we
would
want
to
to
ensure
that
we're
compatible.
I
Yeah
and
I
can
check
in
I
work
at
honeycomb-
I
can
check
in
with
liz
right
now
and
see
how
quickly
I
can
get
a
response
on
that.
Yeah.
E
Tell
us
about
before,
so
I
I
hope
this
was
useful
for
everyone.
So
what
what
I'm
hearing
so
far
is
we
need
snappy
and
we're
gonna
depend
on
the
google's
one
via
the
the
helpers
that
the
grpc
gives
us
or
directly
wrapped,
but
we're
gonna
use
the
the
the
google's
one.
E
We
need
a
zstd
and
we're
gonna
use
from
that
compressed
repo,
because
it's
most
very,
very
used
and
very
active
and
for
lg
for
four
jamie
asked
two
questions,
one
about
v4:
what's
the
problem
with
v4,
it's
only
a
breaking
change
between
v3
and
v4
that
we
don't
care
or
v4
itself
is
unstable
and
breaks
every
time
and
then
that's
a
different
problem.
And
second
thing
is:
do
you
really
need
lz4?
E
E
Because,
besides
honeycomb
is
anyone
else
using
lz4,
I
heard
amazon
is
not
using.
Grafana
is
not
using.
J
I
F
All
right
so
next
one
4087
so.
E
So
wait:
wait,
wait!
So
after
we
get
the
answers
from
lees
for
lg4
yeah,
I
think
we
should
make
a
decision
between
if,
if
we
need
lg4,
let's,
let's
try
at
least
to
upgrade
the
the
helper,
the
grpc
compression
helper
repo
to
the
latest
lz4,
and
then
we
can
take
a
dependency
on
that.
Otherwise
we
can
build
our
own,
our
own
grpc
helpers.
E
H
H
K
Yes,
so
it's
regarding
the
pr
to
remove
the
default
components
from
the
core
as
it
currently
stands.
F
So
this
one
trapped
here
yeah,
so
I
think
we
are
fine
in
removing.
So
you
know
the
builder
is
here:
the
user
is
in
the
command
builder,
so
you
can
change
the
the
make
targets.
Oh
yeah,
okay,
so
this
is
the
first
step
right
then.
The
second
step
is
the
one
that
is
replacing
or
re-implementing
the
make
target.
I
think
this
one
here
can
be
merged
and
the
other
one
can
can
start
being
implemented
right
now.
I
think
we're
ready
for
that.
F
If,
if
possible,
yes,
if,
if
they're,
you
know
willing
to
do
that,
I
would
vote
for
yes,
so
have
both
prs
in
place.
We
then
we
can
review
them
separately,
but
we
merge
them
in
a
short
period
of
time
between
each
other
so
that
we
don't
lose
functionality.
Yeah.
E
That
that
would
be
my
preference
just
not
have
the
loss
functionality,
yeah.
F
So
I
understand
it's
not
who
we're
working
on
on
both
items.
James.
H
G
Yeah,
for
so
there's
4199
and
4200
420
that
you
just
had
open
and
then
419
was
the
first
part
which
is
adding
the
builder
into
or
adding
the
ability
to
the
tools,
but
then
we're
just
waiting
on
the
builder
to
be
moved,
but
now
that
it's
good
to
go,
then
I
can
start
reworking
this
to
fit
the
the
fact
that
the
builder
is
now
in
the
core
repo.
So
I
can
t
I
can
take
a
look
at
this
and
probably
have
this
ready
soon.
G
F
G
Yeah
yeah
no
worries
but
I'll
go
back
to
on
this
soon.
G
K
Nice,
okay,
so
just
to
clarify,
then
the
sequence
will
be
such
that
the
two
pr's
four
one,
nine
nine
and
four
two
zero
zero
will
be
completed.
And
then
afterwards
we
can
review
the
status
of
removing
the
people
components
from
core.
F
All
right,
anthony
40,
69.
H
Yeah,
so
this
issue
is
related
to
moving
the
telemetry
settings
or
the
the
configuration
for
the
internal
telemetry
from
flags
to
configuration.
Bogdan
had
expressed
a
concern
about
not
being
forward
looking
enough
about.
How
do
we
configure
the
otlp
sdk
that
we're
setting
up
this
to
also
manage?
Unfortunately,
I
don't
think
we've
got
a
good
understanding
of
how
that
otlp
sdk
is
is
going
to
be
configured.
H
That's
that's
something
that
that
I
think
needs
to
be
sorted
out
in
the
hotel
go
community
first
before
we
even
know
how
we
can
figure
that
how
we
can
set
up
configuration
for
it.
So
I'm
wondering
if
we
can
move
this
forward,
just
as
a
lift
and
shift
of
that
configuration
from
flags
to
config,
so
that
we
can
get
rid
of
those
flags
and
then
proceed
on
a
separate
path
with
having
a
new
configuration
for
how
do
we
set
up
the
exporters
for
the
hotel
go
instrumentation.
E
H
E
So-
and
I
don't
think
it's
that
useful
so
so
I
would,
I
would
look
into
that
first,
so
I
I
think
we
should
remove
that.
The
other
one
is
adding
the
instance
id.
I
I
think
that's
also
a
very
hacky
thing
that
somebody
from
splunk
I
did
it
so
I
know
I'm
blaming
for
for
my
company,
but
maybe
that
one
as
well,
we
can
we
can
consider
to
remove
as
a
flag.
E
So
I
think
we
should
have
so
the
the
reason
why
I'm
saying
this
is
even
if
we
move
to
con
con
configuration,
we
will
make
the
configuration
unstable
until
we
we
find
the
the
right
config
correct.
E
E
H
H
We
don't
want
to
keep
and
are
there
more
that
we
need
to
add,
and
if
so,
then
we
can
add
to
them,
but
getting
away
from
having
this
stuff
configured
through
cli
flags,
I
think,
is
an
important
part
of
our
our
journey
to
get
away
from
cli
flags
and
get
everything
into
configuration.
Okay,.
E
F
Yeah,
let
me
share
one
thought
on
this
one
here,
so
by
doing
that,
we're
breaking
compatibility
twice
right,
so
we're
breaking
users
two
times
so
one
when
removing
the
flags
and
potentially
the
second
time
when
removing
the
information
from
the
config
file.
H
F
I
guess
the
reason
the
question
is:
is
there
a
strong
reason
to
move
away
from
flags?
I
know
it's
what
we
want
to
do
eventually,
but
do
we
have
any
time
pressure
to
do
it.
H
So
I
think
the
the
rationale
for
moving
away
from
cli
flags
to
configuration
is
that
we
want
the
collector
to
be
usable
as
a
library
that
can
be
embedded
in
other
components,
and
there
are
also
not
just
the
the
core
collector:
that's
that's
getting
removed,
but
the
the
contrib
collector
that
has
its
own
main
routine.
There
are
there's
the
the
lambda
collector,
the
lambda
layer,
collector
that
sets
up
its
its
own
main
and
doesn't
use
the
cobra
command
at
all.
E
H
E
Okay,
I
I
did
not
check
the
the
real
implementation.
I
looked
only
on
the
config
file.
Okay,
so
so
do
do
everyone
agree
to
do
this.
E
We
also
have
to
to
actually
change
the
description
to
say
they
are
deprecated,
but
that's
that's
a
separate.
We
can
comment
there.
Okay,
let's
let's
move
forward
with
this,
then
and
and
then
then,
as
a
follow-up.
We
should
start
thinking
about
the
usefulness
of
this
of
these
configs,
and
maybe
we
should
consider
removing
some
of
them.
E
Anthony
are
you
gonna,
have
the
following
item
to
to
start
looking
into
usefulness
of
these
configs
and
remove
them
if
they
are
not
useful.
H
Yeah
yeah,
I
I
will
follow
up
with
that
then.
So
what
I'm
hearing
is
that
I
need
to
note
that
these
flags
will
be
deprecated.
I
should
just
add
that
to
the
description
of
the
flags,
is
that
correct
yeah,
so
for
for
the
next
release
or
two?
They
will
be
there
and
marked
as
deprecated,
and
then
we
can
follow
up
with
removal
of
the
flags
and
removal
of
the
configuration
for
the
items
that
aren't
needed
and
figure
out
how
we
should
be
configuring.
It
going
forward.
F
E
Okay
sounds
good
good.
I
think
liz
is
here
please.
If
you
are
here,
we
we
had
a
question
about
lz4
yeah,
two
questions:
one:
is
it
something
that
you
used?
L
Not
specifically
lz4
no,
the
things
that
we
think
offer
the
best
savings
for
our
customers
are
going
to
be.
You
know,
gzip
as
standard,
but
also
z,
standard
z
standard
tends
to
be
the
most
efficient
format
for
bytes
on
wire,
which
is
a
thing
that
our
clients
pay
to
talk
to
us.
Okay,.
E
So
the
z
standard,
we
already
decided
to
support
that
it's
already,
it's
supported
by
aws
as
well.
So
we
want
to
to
have
that
and
we
want
to
have
it
for
grpc
and
for
http,
fyi
and
snappy,
because
it's
super
used
so
that
it's
super
used.
I
don't
know
for
whatever
reason,
but
I'm
not
an
expert
in
compression
some.
L
People,
you
know,
still
have
used
snappy
and
haven't
moved
to
z
standard.
Yet,
even
though
z
standard
is
for
most
applications
better
than
snappy
at
this
point,
yeah
yeah,
it's
fairly
common,
the
grpc
ecosystem
for
sure.
So
lv4
is
like
you
know,
on
the
list
of
many
things
you
could
potentially
support,
but
is
not
necessarily
a
hard
requirement
for
us.
Okay.
So
I.
E
L
No
there's
no
bug
in
ld4.
The
problem
was
that
they
removed
an
api
method
between
lv3
and
v4.
They
removed
the
seek
method,
but
if
you
don't
perform
seeking-
which
you
know
you
shouldn't
be
because
you're
just
reading
the
bytes
over
the
wire,
it's
fine.
No
I'm
I'm.
E
Talking
about,
if
potentially
there
is
a
bug,
I
have
no
clue
how
to
fix
it
and
that's
why
less
dependencies
for
for
our
collector
are
better.
I'm
not
saying
that
they
have
a
bug,
but
in
case
there
is
a
bug.
I'm
saying
that
the
collector
maintainers
don't
know
how
to
fix
and
don't
know
how
to
to
deal
with
this
problem.
So
that's
why
I
think
we
should
keep
our
dependencies
low
and
not
support
it.
Unless
somebody
comes
in
yeah.
L
I
think
the
reason
you
might
want
to
do
it
is
if
someone
is
cpu
constrained
but
still
wants
some
reduction
in
bytes
lz4
is
the
best
mechanism,
because
it
is
very
light
on
cpu.
That's
that's
the
reason
to
prefer
it
over
lz4
or
sorry
preferred
over
snapping
z,
standard.
The
snap
and
z
standard
are
a
lot
more
cpu
intensive
for
encoding
and
decoding.
E
E
Okay,
thanks
elise,
that
was
it.
Thank
you,
anthony
and,
and
did
you
understand
what
we
have
to
do.
D
All
right
yeah,
I
understand
so
that,
as
you
mentioned
before,
we
don't
rely
on
the
go
grpc
complexion
and
rather
than
we
will
implement.
E
D
E
We
can
rely
on
them,
but
we
can
rely
on
them,
but
don't
expose
lz4
like
yeah.
Okay,
if
you
want
to
rely
on
them,
but
but
what
you
need
to
do
is
make
sure
that
they,
they
at
least
are
updated
to
the
latest
snappy
and
z
z
standard,
so
make
a
change
to
that
rep.
If
you
want
to
depend
on
that
repo
make
a
change
in
that
repo
to
ensure
that
they
have
the
latest
dependencies
and
we
can
use
that
or
we
can
implement
our
own
own
wrappers.
D
Right
I'll
go
check
and
update
the
issue
or,
and
the
pr.
E
E
Okay,
I
think,
do
we
have
answers
for
all
the
items
here.
E
Also,
we,
I
should
have
said
that
at
the
beginning,
thanks
jurassic
for
for
facilitating
this,
and
also
thanks
for
helping
us
being
a
maintainer
on
the
contribute.