►
From YouTube: 2020-11-05 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).
C
C
E
A
E
E
B
So,
in
order
to
support
the
jaeger
propagator,
the
http
text
map
getter
added
a
method
to
return
the
keys
that
are
used
by
the
propagator,
which
makes
it
no
longer
a
single
method.
Interface,
which
means
you
can't
use
a
lambda
and
apparently
also
broke
lots
and
lots
of
instrumentation
that
had
getter
implementations
that
needed
to
be
updated.
A
E
B
E
A
B
B
F
A
G
E
I
think
we're
good
to
merge
this.
I
think
we
just
wanted
to
create
an
issue,
a
follow-up
issue
for
for
moving
the
sort
of
oshi
stuff
out
of
the
the
agent
itself.
I
mean
the
the
hook,
but
yeah
we'll
merge
this
for
the
release
for
zero
ten
zero.
F
A
H
G
A
E
Sergey
did
do
you
need
this
in
zero?
Ten
zero,
I
mean,
do
you
want?
Are
you
wanting
this
as
much
as
you're
wanting
this
one
or
it's
not
a
big
deal.
E
E
Do
you
have
customers
that
are
using
baggage.
G
G
E
It
looks
it
looks
correct
for
me.
I
didn't
understand,
until
carlos
sort
of
brought
that
up
about
the
baggage
propagator
should
be
outside
of
our
multi-propagator,
which
makes.
D
E
Because
the
multi-propagator
short
circuits
once
it
finds
a
span,
context
a
header
and
you
don't
want
the
the
baggage
you
want
to
always
extract.
A
E
All
right,
any
other
topics
who
do
we
have
here:
mateosh
yeah,
thanks
for
your,
I,
like
your
abc
def,
I
haven't
looked
today.
If
there's
now,
probably
ghi.
E
D
This
okay,
there's
there's
a
load
of
lines
of.
D
E
Jason
keller,
any
have
you
thought
any
more
about
the
distro
stuff.
C
Yeah
not
quite
yet,
our
focus
was
elsewhere
this
past
week,
but
we're
about
to
start
poking
into
that.
So
hopefully
it's
pretty
straightforward.
But
if
we
have
questions
we'll
we'll,
definitely
let
you
know
or
if
we're
able
to
kind
of
draft
a
doc
of
the
process
we'll
send
that
your
way
as
well.
A
You
you're
saying
about
like
vendor,
distro
repackaging
the
agent
yeah.
Regarding
that
I
started
to
put
like
a
demo
repository,
which
shows
all
these
extension
hooks
that
we
already
have
that
you
can
provide
how
to
like
pre-configure
your
distribution
for
your
needs.
A
E
We
I
know
you,
I
remember
you
were
asking
about
that
in
the
maintainers
meeting
of
repo,
for
that
in
the
meantime,
shall
we
put
it?
A
That,
as
was
suggested,
I
will,
I
will
make
a
repo
in
my
personal
account,
share
that
first
for
the
for,
like
the
first
feedback
for
the
first
round
of
feedback,
hope.
So
that's
by
the
way.
That's
good
motivation
to
do
that
before
next
monday,
maintainers
meeting,
then
I
can
show
it
there
and
like
ask
the
first
feedback
from
the
maintainers
yep.
A
E
Cool
and
then
will
you
post
in
that
issue
that
jason,
okay,
awesome.
E
No,
what
are
you
jay
keller?
It's.
C
E
A
E
Oh,
we've
got
tyler,
hey
tyler,
hey
I'm
hoping
next
week
to
start
looking
at
catching
us
up
on
various
datadog
work
merging
over
because
there's
definitely
some
good
stuff.
That's
been
happening
there.
A
E
Were
made
well,
that's
that
that's
not
on
tyler!
That's
I
mean
there's,
there's
a
bunch
of
folks
over
in
datadog
doing
these
prs,
but
my
plan
is
to
bring
them
over
one
pr.
E
At
a
time
I
mean
bring
them
over
as
separate
prs
so
that
we
can,
you
know,
discuss
and
review
more
easily
and
things
that
are
not
controversial.
We
can
merge
quickly
and
things
that
are
controversial.
We
can
merge
slowly.
E
E
You
all
right!
Well,
let's,
let's
look
at
the
weekly
digest
and
then.
H
What
one
question
I
wanted
to
throw
out
before
that-
and
this
might
actually
be
something
that
would
so
something
I've
been
trying
to
discuss
internally
within
datadog-
is
how
how
can
we
start?
You
know
pulling
more
stuff
together
and
there
are
some
things
so
like
if
we
were
to
start
doing
a
lot
of
the
instrumentation.
H
I
think
that
there's
enough
that's
differences
in
philosophy
and
such
that
might
be
difficult,
but
one
area
that
I
think
that
would
be
you
know
fairly
non-controversial-
is
being
better
about
sharing
the
context,
propagation
instrumentation
and
just
because
I
think
context
propagation
is
less,
is
more
universal,
like
there's
less
to
debate
about
it,
and
the
semantics
around
that
so
I
was
trying
to
think
is:
is
there
something
that
we
could
do
there
to
make
that
easier?
E
H
I
mean
so
like
I,
I
hope
and
want
to
get
to
that
point
eventually,
but
I
was
just
trying
to
think
is:
would
that
be
a
good
starting
point
of
like
focusing
on
context
instrumentation
rather
than
something
that's
dealing
with
spans
and
traits
and
traces.
E
A
A
E
Yeah
I
mean
I
understand
your
point
tyler
about
that
spans.
I
mean,
there's
more,
there's
the
whole
span
model
versus
the
context
model.
It's
is
smaller.
The
the
other
side,
though,
is
the
context
like
we're.
We've
been
struggling
a
lot
with
the
context
propagation
and
using
we
now
depend
on
so
honorable
had
built
out
in
the
open,
telemetry
api
we're
now
not
using
grpc
using.
H
Yeah,
I
understand
that
and
and
honestly
like
that's
something
that
I
think
that
we
would
be
okay,
bridging
the
other
reason
that
I'm
suggesting
this
is
because
I
feel
like
of
the
work
that
we've
done
in
on
the
datadog
side.
Recently,
most
of
it
has
been
most
of
the
improvements
I
think
have
been
around
context
propagation
and
I
feel
like
that
would
be
a
good
way
for
us
to
like
maybe
bring
that
back
over
a
little
bit.
H
So,
honestly,
like
we,
we've
done
relatively
little
instrumentation
elsewhere.
Most
of
the
work
has
been
around
improving
and
making
context
propagation
more
consistent.
So,
for
example,
we
no
longer
have
just
a
generic
java
executor
service
instrumentation.
H
They
we've
kind
of
split
that
up
to
have
instrumentation
specific
to
a
lot
of
the
most
common
executor
implementations.
So,
for
example,
there's
a
separate
instrumentation
for
a
thread
pool
executor,
that's
separate
from
fork
joint
executor-
and
this
is
this-
is
to
take
advantage
of
the
more
specific
behaviors
of
each
of
those
ins.
Each
of
those
implementations.
A
You
do
have
support
for
for
for
joint
pool
and
parallel
streams.
I
believe
so
bring
it
on
bring
it
on.
H
H
So
anyway,
I
just
wanted
to
throw
that
out
there.
As
like
a
point
of
discussion,
I
didn't
expect
to
have
any
like
answers
or
any
anything
specific
that
we
could
take
away
from
it,
but
just.
E
Yeah
I
mean
in
general
yeah.
Let
us
keep
us
updated
on,
I
mean
I
would
love
to
get.
You
know
you
all
on
to
some,
if
not
all
of
but
some
others.
H
E
H
In
my
opinion,
because,
honestly
to
me,
I
feel
like
they
are
relatively
orthogonal
concepts
like
having
instrumentation
that
starts
and
stops
spans
and
manages
spans
and,
and
that
doesn't
feel
like
it
necessarily
needs
to
be
tied
to
context
propagation
now
context
propagation.
In
terms
of
like
inject
and
extract,
I
I'm
not
suggesting
pulling
that
out
what
I'm
referring
to
in
terms
of
this
context,
propagation
is
specifically
around
the
yeah
yeah
in
process.
Exactly
yeah
yep.
E
Cool,
oh
just
to
ask
on
this
broader
group,
because
we
were
discussing
last
night
with
nikita
and
honorag.
The
the
java
repo
has
started.
E
Changelog
entries
in
pr's
or
lisa
is
considering
that
and
so
we're
discussing
if
that
makes
sense
or
how
to
implement
that
in
this
repo,
and
there
was
some
concern
about
requiring
that
changelog
entry
because
of
conflicts,
I
guess
the
experience
with
in
the
spec
repo
of
the
conflicts
with
the
changelog,
but
at
the
same
time
the
chain
having
something
in
the
pr
would
help
us
with
building
the
building.
The
change
log
come
release
time,
make
it
easier
to
cut
new
releases.
E
So
I'm
not
sure
what
curious
if
people
have
had
here,
what?
If
anything,
has
worked
well
for
people
here
or
not
worked
well
that
they
may
be
able
to
share.
E
Oh,
I
thought
you
were
sorry
based
on
this
comment.
B
So
anyway,
I
think
the
idea
of
having
it
in
the
pr
like
I'm,
not
sure
where
to
put
it,
does
it
go
in
the
comment.
Does
it
go
in
the
pr
description
because
pr
descriptions
don't
show
up
in
the
git
history
right
so
anyway,
I
don't
think
there's
a
great.
I
don't
think
we
have
a
great
solution
for
it
at
the
moment.
A
A
A
A
B
I
mean,
I
think,
the
the
best
way
to
do
it
and
I'm
using
best,
maybe
in
a
little
bit
of
scare
quotes,
is
if
there's
like,
if
there's
a
commit
or
when
the
commit
is
squashed
and
merged
with
some
sort
of
identifying
like
chain
capital
change,
blog
or
something
like
that.
Because
then
you
could
grep
through
the
git
log
and
just
yeah
grab
those
out
of
there.
F
B
B
E
Cool
yeah,
I
thought,
would
be
great
to
share
to
do
the
same
in
both
repos
and
one
one
thought
we
had
was.
E
It
would
be
like
requiring
this
of
sort
of
core
contributors,
people
who
are
contributing
often
but
for
sort
of
people
who
are
just
sporadically
contributing,
not
necessarily
imposing
that
extra
requirement
on
them.
Or
you
know
we
could
add
a
comment
in
there
for
a
proposed
change.
Log
entry.
I
Yeah
for
what
it's
worth,
we
at
new
relic
have
decided
to
keep
a
change
log
file
and
we
want
to
be
adding
to
that
file
on
every
commit,
but
it
because
it
then
it
is
a
nice
place
just
to
crib
release
notes
from,
but
it's
kind
of
duplicated
work
right,
you're,
putting
the
same
text,
maybe
in
the
pr
that
you
are
inside
of
the
change
log.
So
and
it's
super
super
awful.
If
you
have
a
busy
project
because
yeah.
H
Yeah
we
had
a
similar
problem
at
datadog
with
we
were
using
a
rev
api
plug-in
to
to
do
validation
on
you
know,
api
breaking
changes,
and
you
know
in
order
to
do
that,
you
had
to
have
a
yaml
file
that
tracked
any
of
the
allowed
breaking
changes
which
definitely
caused
problems
in
a
lot
of
places.
E
E
Okay,
cool
and
yeah
anorak
had
some
some
thoughts.
Also
so
yeah
that'll
be
great.
We'll
chat
about
that
next
week.
E
E
I
had
lots
of
updating
to
the
latest
snapshot
by
onorag.
All
of
these
api
open,
telemetry
api
changes.
E
Let's
see
this
is
related
to
how
we
run
the
smoke
tests,
so
we
publish
these
docker
containers
that
have
the
apps
that
get
run
separately
from
the
actual
test
runner
in
order
to
not
have
to
build
those
docker
containers
with
each
ci
run,
but
that
also
caused
some
issues
of
which
tests
were
run
against
which
docker
containers.
So
now
they
have.
A
E
E
Yeah,
oh
yeah,
our
latest
depth
tests.
So
we
don't
run
the
latest
depth
test
during
prs
because,
as
a
new
version
of
like
grpc
gets
released,
it
will
just
arbitrarily
start
failing
somebody's
pr
and
that's
confusing
for
them
because
they
didn't
make
any
changes
to
that.
But
the
downside
is
that
we've
been
finding.
Also
is
that
when
people
introduce
new
instrumentation
like
the
camel
apache
camel
instrumentation,
we
don't
run
the
latest
depth
test
against
that
pr
either.
E
And
so
we
find
that
those
never
passed
at
all
and
it's
in
the
nightly
build,
and
so
we
do
catch
it
and
get
that
fixed.
But
I
don't
know
if
we
come
up
with
something
better
at
some
point.
E
Smoke
tests-
oh
yes,
this
is
this
was
clever
for
adding
so
end
to
end
test
with
jaeger
and
zipkin.
So
we
have
otlp
our
otlp
end-to-end
tests
build
a
use,
the
build
a
little
grpc,
fake
ingestion,
service,
fake
collector
service
and
the
otlp
collector
sends
to
that.
And
then
our
tests
read
that
just
to
verify
the
spans
were
collected,
but
we
actually
are
sending
to
the
real
collector
and
we
have
the
real
collector
then
sending
to
our
exporting
otlp.
E
So
what
what
nikita
did
here
was
the
the
open
telemetry
collector
also
knows
how
to
listen
for
jager
and
zipkin.
So
we
don't
didn't
need
to
actually
add
the
real
jaeger
and
real
zipkin,
and
you
know,
read
the
span
data
from
those
we're
able
to
just
also
have
the
collector.
Listen
for
jaeger
and
zipkin.
Have
those
tests
talk
to
that
and
it
still
talks
to
our
same
then
otlp
grpc,
fake
back
end.
E
Updating
to
latest
snapshot,
this
was
cool
on
a
new
setting
that
gradle
did
andrag
ever
link
to
where
no,
he
didn't
link
to.
He
said
the
great
old.
E
No
hey
all
right
so
yeah,
so
we
had
we've
had
problems
in
our
repo
with
gradle
when
you
run
it
locally,
it
spawns
too
many
workers
and
your
machine
just
gets
unresponsive,
so
we
had
previously
set
max
workers
to
two
in
an
attempt
to
help
with
this,
but
this
priority
low,
at
least
for
me
that
worked
really
well
I'll.
Show
you
the
difference
in
cpu,
so
the
this
is
now,
whereas
before
so
before,.
E
This
was
what
was
happening,
but
what
the
bad
part
was,
while
this
was
happening
like
my
machine
was
unresponsive.
It
took
like
15
seconds
to
get
to
even
take
a
screenshot,
whereas
with
this
low
setting
somehow
like
it
uses
the
cpu
amazingly
efficiently
and
the
snap,
the
the
it
doesn't
freeze
up
my
machine,
so
I
don't
know
what
they
did,
but
I'm
happy.
E
Update
the
latest
snapshot
manual
dispatch.
Oh,
this
is
the
github
action
stuff,
oh
yeah,
so
oh
did
you
wanna
no.
B
E
This
is
a
really
nice
change,
so
we
introduced
ahmatesh
introduced
this
concept
of
instrumentation
module.
So
what
was
happening
before
is
some
of
our
instrumentation.
E
We
instrument
multiple
classes,
and
so
we
end
up
with
multiple
instrumentations
and
each
instrumentation
in
our
model
has
its
own
list
of
helper
classes
that
we
need
to
inject
its
own
muzzle
checker
reference
checker.
That
needs
to
be
run,
and
so
we
often
extend
this
base
class
that
we
put
all
of
those
things
common
in,
but
sometimes
not,
and
even
then,
when
it's
in
the
base
class
we
end
up.
E
You
know
I
mean
trying
re-injecting
those
helper
classes,
I
mean
we
check
and
we
don't
re-inject
them
twice,
but
there's
extra
overhead
and
and
the
biggest
problem
really
with
that
approach
was
the
the
muzzle
some
instrumentation
would
get
applied,
because
the
muzzle
would
would
not
thwart
it
while
other
instrumentation
might
get
applied.
E
So
what
happens
now?
Is
instrumentation
module
there's
only
one
per
per
instrumentation
module
for
get
gradle
module
and
then
there's
multiple
type
instrumentations
to
handle
each
of
those
and
at
the
instrumentation
module.
Now
everything
is
there's
just
one
of
those
one
instrumentation
name,
one
set
of
helper
classes
that
gets
injected
once
one
and
then
the
most
important
thing,
I
think,
is
the
one
muzzle
for
all
of
those
type
instrumentations
so
that
we
know
now
that
the
whole
module
will
get
instrumented
or
none
at
all,
which
is
a
big
improvement.
E
Awesome
and
so
now
he's
going
through.
That's
what
I
was
laughing
at
the
all
of
his
abc
he's
going
through
module
by
module
and
making
these
updates
to
everywhere,
which
yeah.
E
Yeah,
oh
right,
right
yeah.
So
in
order
to
not
do
the
mass
shift
all
at
once,
shifting
over
leaving
the
old
stuff
infra
behind
and
then
once
it's
all
done,
then
deleting
the
old
infra.
E
Yeah
nikita's
been
moving
us
to
github
actions
for
for
a
while,
now
and
and
working
out
all
these
stability
issues
and
gradle
caching
issues
and
before
build
time
performance
issues.
So.
B
If
you
run,
if
you
run
into
any
I've,
run
into
a
bunch
of
seg
faults
now
running
on
circles
on
github
actions
in
ubuntu
like
at
least
three
or
four
times
now,
the
jvm
has
seg-faulted.
I
was
wondering
if
you
all
had
seen
that
in
your
region.
What
do
you.
F
Do
with
jvm
nothing,
that's
my
point.
B
F
B
A
A
E
So
one
one
thing
we
have
noticed
with
the
github
actions
and
that
rerun
is
that
we
can't
rerun
an
individual
job.
We
can
only
rerun
everything.
B
F
B
A
E
This
is
interesting
and
massive
instrumentation
and
what's
interesting
about
this,
is
that
the
apache
camel
folks
have
instrumented
their
new
versions
of
their
with
open
telemetry
api
directly,
which
I
think
we're
all
think
is
both
cool
and
scary.
And
but
this
is
to
add
that
instrumentation
for
older
versions
before
they
started
instrumenting
with
open
telemetry,
although
even
I
don't
know
does
anybody
know
how
that
works
with,
because
they're,
probably
using
an
older
version
of
the
api
that
we're
not
interrupting
with
currently.
A
E
So
does
this
instrumentation
work
on
new
on
the
latest
apache
camel
also
or.
B
A
A
E
Okay,
so
the
idea
is
on
the
newest
one:
people
should
apache
camel,
will
hopefully
stay
up
to
date
with
ga
and
then
we'll
interop.
A
E
Yep
agreed
cool
any
thing
anybody
thought
of
while,
in
the
meantime,.
A
E
I
actually
want
this
one,
because
this
is
part
part
partially
how
we
draw
the
the
yeah
yeah.
We.
E
D
B
B
Okay,
I
will.
I
will
not
rerun
the
next
one
and
send
you
the
link
and
show
you
the
show
you
the
the
badness,
if
you're
asleep,
I
can't
promise
you
I'll
rerun
it,
though
I'll
try
to
at
least
grab
the
log.
So.
E
All
right
anybody.
A
B
E
H
H
On
the
data
dog
repo
for
a
while.
A
A
B
A
It
provides
you
more,
but
if
you
want
to
see
just
one
single
build,
scan
or
tens
separate
build
scan,
then
that's
totally
free
of
charge
and
it's
sometimes
very
convenient
to
understand,
for
example,
why
a
build
is
taking
so
long
is
it
configuration?
Is
it
dependency
download
the
network,
why
your
build
cache,
doesn't
work,
etc.
E
This
is
pretty
cool
this
feature
because
we
auto
rerun
stuff,
auto
rerun
tests,
and
this
will
tell
us
which
ones
were
flaky,
but
it
still
passes,
but
we
can
go
back
and
see
and
work
on
flaky
ones
without
them
blocking
our
build.
B
Thing
I
will
create
an
issue
in
the
java
repo,
so
someone
who
knows
gradle
can
end
github
actions
can
worry
about
it.
A
Well,
it's
it's
a
tool
of
service
created
by
sergio
gorov.
If
you
know
the
guy,
which
essentially
log
output,
aggregation
unlock,
result,
aggregation.
E
A
E
A
Okay,
cool
and
what's
good,
what's
good
for
that,
as
we
run
our
built
on
d
on
different
java
versions,
we
have
big.
Gradle
builds
come
separately
for
for
them,
but
here
you
have
that
all
on
the
same
page,
so
you
receive
like
three
three
or
four
lines
like
columns.
So
that's
for
java,
8,
java,
11
and
java
50.
E
Cool
hey:
we
are
at
five
minutes
till
which
is
our
attempted
official
stopping
time,
but
any
last
questions,
thoughts,
comments.