►
From YouTube: 2020-10-01 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).
B
B
A
All
right,
we
have
a
bunch
of
things,
the
agenda,
so
I
will
prioritize.
A
A
C
A
A
We'll
give
a
couple
minutes,
hoping
that
marching
is
able
to
join.
A
Why
don't
we
start
nikita
a
cup
with
since
we're
here
the
prometheus
exporter
factory,
naming?
I
saw
your
comments
and
agree
that
the
so
I
think
I
had
su
suggested
a
possible
option
instead
of.
A
Prometheus
metric
instead
of
producer
metric
producer
customizer,
so
I
I
think
this
is
primarily
your.
What
you're
pointing
out
is
that
this
is
a.
This
name
is
confusing.
A
Cool
so
I
suggested
metric
collector
here.
I
think
it's
a
little
better,
but
it's
maybe
not
completely
better.
B
A
Cool
so-
and
I
thought
I
saw
carlos
and
then
not
okay
cool.
Why
don't
we
start
right
off
with
spring
cloud?
Sleuth
plus
open
telemetry,
so
marcin
had
provided
these
sort
of
I
was
asking
about
since
we
haven't
broken
out
very
many
of
the
manual
or
library
instrumentation.
A
D
Before
we
go
to
that,
we
might
have
actually,
we
might
actually
go
to
the
questions
first,
because
it
actually
is
combined
to
some
extent.
Why
is
it
so
because
and
the
question
in
the
list,
there
is
actually
oh,
it's
not
there.
So
what
I
wanted
to
discuss
is
that
I've
seen
that
you
have
in
the
auto
instrumentation
repo.
D
You
have
some
spring
instrumentation,
you
have
spring
boot
instrumentation
and
now,
if
sleuth
is
to
be
open,
telemetry
compliant,
it
doesn't
make
much
sense
to
actually
have
it
in
two
places
right.
So
my
understanding
is
because
we
don't
want
to
compete
against
auto
right,
because
that
doesn't
make
sense.
D
So,
in
my
opinion,
the
way
it
should
be
done,
assuming
that,
of
course,
so
I'm
going
to
put
it
outside
the
bracket,
saying
if,
assuming
that
sloof
is
open,
telemetry
compliant
right
can
work
open
telemetry.
So
I'm
not
going
to
repeat
myself,
so
I
think
that
the
proper
way
to
do
it
would
be
that
sleuth
is
the
de
facto
standard
for
spring
boot
or
spring
cloud-based
applications
right,
because
we
know
how
to
do
it
like
we
do
it
on.
D
We
do
spring
boot
spring
clouds,
so
we
know
how
to
properly
set
up
auto
instrumentations.
I'm
not
saying
that
you
don't
right,
but
let's
say
we
do
it
on
the
daily
basis,
we're
happy
to
defer
that
expertise
to
you.
That's
that
I
think
it
makes
it
makes
more
sense.
So
that
way,
you
don't
have
to
create
those
things
on
the
on
your
side
and
then
we
don't
have
to
you
know,
take
them
in,
and
you
know,
do
some
stuff
around
it.
D
So
how
we
do
it
with
brave
right
now
is
that
brave
creates,
let's
say,
instrumentations
the
way
you
do
as
well
right
so,
for
example,
mongodb
instrumentation.
So
what
actually
becomes
is
an
auto
configuration
for
those
instrumentations
right.
So
if
you
have,
for
example,
mongodb
instrumentation,
we
can
set
up
auto
configuration
with
all
the
properties.
D
We
have
computational
classes
conditional
whatever
and
set
up
the
beans
for
mongodb
instrumentation
right,
and
this
is
what
we
do
for
brave
and
it
it
works
pretty
well
right
because,
let's
say
the
brave
community
can
focus
on
doing
instrumentations
and
we
are
focusing
on
setting
them
properly
up.
So
first
question
here
is
like:
does
it
make
any
sense.
A
A
D
That's
a
great
comment
actually
because
I
had
a
discussion
like
yesterday
with
somebody
and
they're
asking:
why
is
spring
cloud
sleuth
spring
cloud?
Actually
because
it
does
all
the
work
for
all
the
instrumentation.
It's
not
necessarily
related
to
cloud
so,
but
I
guess
it's
spencer's
too
late
to
rebrand
right.
E
D
Yes,
absolutely
sprinkled
sleeve
is
not
only
for
spring
cloud.
We're
instrumenting
a
lot
of
things,
basically
whatever
so
right
now
we
are
this
extremely
brave
specific.
So
if
the
community
says
hey,
we
would
like
to
have
grpc
support
right
and
we
get
a
couple
of
votes,
so
people
are
interested
in
that
we
can
start
doing
the
auto
configurations
for
spring
boot
based
applications
with
grpc
right.
D
So
we
could
do
exactly
the
same
thing
for
for
otel
and
those
the
list
that
I've
presented
was
the
things
that
we
have
already
in
brave
right
or
done
manually
by
ourselves.
For
example,
reactor
right
lettuce
is
also,
let's
say,
led
by
mark
palu
right,
so
it
was
also,
let's
say,
prepared
for
being
working
with
spring
cloud.
Sleuth,
oh
yeah,
so
so
reactor
is
not
in
sleuth
from
these
yeah.
So
this
this
is
interesting.
It's
left
for
j
log
back
because
I
couldn't
find
it
in
autel.
D
So
what
we
do
is
we
automatically
when
you
add
sloof,
we
change
the
logging
pattern
and
we
inject
traces,
trace,
ids
and
span
ids
and
stuff
like
that.
So
do
you
do
that
as
well?
For
for
those
logging
frameworks,.
B
D
Because
I've
seen
some
things
there
in
the
code
and
fortunately
you're
using
trace
id
and
spawn
id
exactly
as
you
wrote
it,
so
do
we
so
so
if,
since
we
have
the
environment
post
processor,
whatever
we
have
some
internals
that
already
refer
to
mdc's
trace
id
span
ids.
So
assuming
that
your
stuff
works,
fine,
we
wouldn't
have
to
change
anything
so
that
could
be
actually
pushed
to
core
right.
D
C
D
So
this
is
exactly
the
the
thing
that
the
reactor
is
done
in
sleuth.
We
have
oh
yeah.
I
mean
this
is
the
parity
of
sleuth
and
brave,
because
in
slu
for
example,
we
have
spring
cloud
gateway
support,
but
it's
since
it's
not
brave
specific.
D
F
Hey
so
quick
question
with
what
you're
proposing
are
you
suggesting
that
hotel's,
auto
instrumentation
depends
on
sleuth
or
sleuth
depends
on
otel's,
auto
instrumentation.
D
A
That
I
will,
I
will
update
so
the
discussions
that
I
think
bogdan
and
marcin
started.
I'm
just
talking
about
the
discussions.
Kind
of
that
ewan
bogdan
had
initially
had
started
and
the
the
plan
that
marching
is
has
spiked
a
an
open,
telemetry
and
implementation
of
the
open,
telemetry
api
that
uses
brave
under
the
hood
and
the
plan.
The
proposal
is
to
have
spring
cloud.
Sleuth
talk
directly
to
open,
telemetry
api,
so
hard
code.
A
D
Yeah,
that's
that's
the
first
spike
because
right
now,
I'm
working
on
the
second
one,
we're
actually
with
we're,
creating
a
an
api
there
in
sleuth
to
abstract,
both
brave
and
open
to
limitations,
so
we're
just
checking
our
our
options.
D
A
And
so
tyler,
I
think
we're
talking
about
what
we
refer
to
as
library
instrumentation
here,
as
opposed
to
java
agent
instrumentation.
F
That's
kind
of
what
I
thought
so
the
idea
being
that
sleuth
would
depend
on
the
open,
telemetry's
library,
instrumentation.
B
D
Yeah
some
things
I
do
instruments,
so
the
thing
is
that,
for
example,
with
grpc
for
the
grpc
is
a
good
example.
So
with
grpc,
what
we
do
is
we
have
a
spring
boot
grpc
starter
right,
so
we
don't
write
it
ourselves
and
we
have
brave
grpc
tracing
so
brave
knows
how
to
instrument
this,
and
we
have
the
glue
right.
So,
okay,
we
would
have
something
similar
from
auto,
so
we
have
the
spring
boot
grpc
starter.
We
have
the
auto
grpc
tracing
and
we
provide
the
glue
how
to
set.
B
It
up
okay,
so
you
still
take
our
library
instrumentation
and
you
just
glue
it
with
for
spring
break
within
application
context.
D
D
D
Yeah,
okay,
and
if,
for
example,
we
have
the
sprinkler
gateway
is,
is
a
good
example
here,
so
we
have
sprinkler
gateway,
so
I've
managed
to
do
let's
say,
because
brave
doesn't
have
instrumentation
for
sprinkler
gateway,
so
I
wrote
instrumentation
for
sprinkler
gateway
myself
using
let's
say
some
or
I
will
try
to
do
it
with
some
abstraction
of
whatever
choosing
right
and
then,
regardless
of
whether
it's
brave
or
other.
That
should
work
right.
A
Portfolio,
so
I
think
this
was
getting
to
nikita's
question
about
were
the
other
spring.
What
about
other
spring
libraries.
D
That's
a
great
question:
yeah
yeah,
and
this
is
what
I
wanted
to
ask,
because
I've
seen
that
ins
you
have,
for
example,
I'm
looking
to
the
side
because
I
have
notes
there.
Why
do
you
have,
for
example,
spring
web
in
version
three
or
something?
This
is
click
super
ancient
and
the
question
is:
do
you
have
like
those
old
libraries,
because
you
want
to
instrument
a
legacy?
Let's
call
them
spring-based
apps
via
an
agent
or
is
it
just
like
for
no
particular
reason.
A
Yeah,
so
the
version
number
in
them
in
the
module
names
is
the
minimum
version
that
they
support
and
the
I'd
say.
The
main
reason
we
support
you
know.
Pretty
old
versions
of
these
libraries
is
really
because
of
for
the
java
agent,
because
customers,
who
have
you
know,
legacy
apps.
A
We
understand,
like
we've,
had
this
discussion,
also
where
we
agree
that
people
on
old
versions
aren't
going
to
be
adopting
open,
telemetry
manual,
instrumentation
they're
not
going
to,
but
they
would
still
like
to
throw
on
a
java
agent,
not
touch.
You
know
not
crack
open
their
source
code,
throw
in
a
java
agent
and
get
telemetry
from
it.
F
I
could
also
give
a
little
bit
more
color
there.
The
reason
for
going
for
such
an
old
version
is
is
just
practicality,
like
the
things
that
we
were
instrumenting
on,
that
were
simple
enough
and
commonplace
enough
that,
without
breaking
anything,
we
could
go
to
that
old
version.
So
it's
the
the
way
I
generally
wrote.
That
is,
I
started
targeting
a
specific
version
and
find
the
instrumentation
points
that
make
sense,
and
then
I
check
to
see
okay
without
changing
anything.
D
Yeah,
it
makes
makes
perfect
sense,
so
we
will
not
be
doing
this,
so
we
will
be
going
with
the
spring
boot
and
sprint
cloud
versioning
since,
like
spring
cloud
is,
it
depends
on
spring
boot
right,
so,
whatever
spring
boot
provides,
we
will
be
providing
this
as
well,
so
here
we
will
not
be
competing
against
each
other
at
all.
Right
because,
for
obvious
reasons
right
we
are,
we
will
be
targeting
boot
based
applications
right.
D
F
Yes,
one
other
question
I
have
is
what
what
do
you
envision
as
the
result,
if
somebody
has
both
the
auto
instrumentation
from
hotel
and
spring
sleuth.
A
Right
now,
merchant
yeah-
this
is
a
he
asked
that
so
we
do
have
that
as
we
have.
B
B
B
The
point
the
question
here
is:
who
who
should
back
off
auto
instrumentation
or
library
instrumentation?
I
think
that
if
there's
an
agent,
I.
D
F
Because
it
would
be
very
difficult
for
the
agent
to
back
off
because
it's
applying
everything
before
the
application
starts
exactly
right.
D
B
G
C
A
Yes,
you
do
okay,
yeah,
so
this
is.
These
are
my
thoughts
on
it,
basically
that
I,
I
think
that
the
auto
instrumentation
should
take
precedence,
and
the
reason
is
that
is
more
from
a
ops
perspective
that
it's
easier
to
upgrade
to
keep
upgrading
the
java
agent
versus
upgrading
the
manual
instrumentation
where
that
applies
and
yeah.
If
they,
if
they
don't
want
a
java
agent,
they
should
just
take
that
off.
F
So
another
thing
that
we
could
consider,
I
think
that
the
original
intention
around
named
tracers
was
to
provide
the
ability
for
agents
to
to
kind
of
inject
no
op
tracers
for
particular
named
sets
of,
for,
for
specifically,
I
guess
for
manual
instrumentation,
allowing
the
tracer
to
override
manual
instrumentation,
and
so
this
might
be
another
possibility
for
for
something
that
we
could
use
here.
A
Yeah
and
we
do
have
the
ability
to
turn
off
people
can
turn
off
specific
instrumentations
in
the
agent,
so
that
would
still
be
a
possibility
like
if
they
wanted
to
specifically
turn
off
one
of
our
spring
instrumentations
to
prefer
the
manual
one.
D
The
same
so
whenev
whenever
we're
doing
auto
configurations,
this
is
something
that
I
haven't
seen
in
auto.
So
when
we
are
doing
auto
configurations
the
boot
base
of
the
configurations
we
like
in
99
of
cases,
we
provide
properties
to
disable
them.
D
B
G
D
Place
on
that
toe,
actually
nick
after
aft,
like
two
days
after
we
discussed
the
reactor
stuff-
and
you
mentioned
the
kotlin
call
routines,
I
got
a
new
students
to
live
for
kotlin
core.
C
D
We
can
we
can
try
to
figure
it
out,
for
example,
as
I
as
I
talked
to
nikita,
and
actually
this
was
spencer's
and
one
more
person
suggestion
for
reactor.
Sometimes
it's
the
best
to
just
tell
the
user
to
be
explicit
and
instead
of
doing
this,
auto
instrumentation
of
the
reactor
flow,
for
example,
for
web
flux,
you
have
access
to
the
server
web
exchange
object,
which
is
essentially
like
a
request
comes
in
and
you
have
the
server
web
exchange
object
that
has
all
the
attributes
and
stuff.
D
D
D
D
Speaking
of
which
there's
one
more
thing
here,
because
we
once
we
managed
to
to
figure
out
a
lot
of
stuff
here,
we
have
to
sit
down
and
see
because
auto
uses
a
lot
of
statics
right
to
get
stuff
from
from
the
contest
propagators,
for
example,
stuff
like
that
I've
seen
spring,
doesn't
do
it
so,
for
example,
when
I
started
to
do
auto
configuration
for
auto,
because
I
didn't
know
that
there's
one
in
in
auto
I,
for
example,
context
propagators
for
me
is
a
great
concept
of
a
beam
that
is
registered
and
you
don't
access
it
statically.
D
You
want
to
inject
it
right
and
that's
not
the
problem
from
the
point
of
view
of
the
things
that
we
would
be
instrumenting,
it
might
be
the
problem
in
the
libraries
that
are
already
instrumented
right
and
they
use
statics
right.
So
he
will
have
to
be
sure
that
it's
working
fine,
I
mean
what
I
did
was
that
when
I
registered
the
bean,
I
also
set
it
via
the
static
accessors
right,
but
we
have
to
be
sure
that
this
actually
works.
A
D
A
A
Yeah,
it
may
be
worse
than
without
meeting
without
the
u.s
folks
meeting
with
honorag
to
discuss
that,
because
yeah.
D
A
Great
yeah,
I
I
I'm
chatting
with
him.
We
chat
at
this
evening
our
time
tomorrow
morning,
his
time
also
because
of
we
have
multiple
meetings
because
of
times
of
fun
with
time
zones
you
have.
A
I
wanted
to
touch
on
this
because
marchand,
if
you
one
thing
that
was
kind
of
interesting
about
the
path
of
writing
a
brave
sdk
for
the
open
telemetry
api
is,
if
you
did,
if
we
did.
If
we
went
down
that
route
on
the
java
agent
could
also
have
that
option,
which.
D
We
had
about
that
with
bogdan
and
he
said
that
from
my
understanding
that
the
auto
folks,
so
you
guys-
I
don't
know
if
you
know
that
you
were
interested
in
writing
the
bridge.
So
that's
there
is
an
option
for
people
to
choose
whether
they
want
to
use
the
old
olympia
or
the
brave
one
which
would
be
fine
for
like
the
community.
I
guess.
A
Well,
I
think
primarily
we
want
to
if
that,
if
that
is
the
route
that
you
want
to
go,
I
think
that
we
we
discussed
that
we
would
take
that
bridge
or
layer
since,
especially
since
it
would
just
be
straight
from
open,
telemetry
to
brave
and
not
a
sleuth
specific
spring
specific
thing
that
we
would
pull
that
into
the
sdk
repo
and
maintain
that
and
then
we
could
potentially
use
that
in
the
java
agent.
Also.
A
But
if
that's
not
the
route
that
you
go,
then
you
know
it,
it
wouldn't
become
a
priority
for
us.
It
would
be
something
interesting
if
somebody
else
wants
to
do
that,
but
we
probably
would
defer
on
that
for
now
sure.
A
On
which
route
you
want
to
go,
and
we
would
like
to
help
you.
D
D
So
I'm
I'm
spiking
spiking.
So
if
I'm
gonna
keep
you
posted
on
how
it's
going
right.
A
D
Yes,
and
no
because,
let's
say
from
from
the
from
the
point
of
view
of
sleuth,
regardless
of
how
it's
done
at
the
end,
I
would
be
just
you
know,
registering
some
beans
that
you
provide.
So
I
can
tell
you
how
it's
done
in
brave.
So
let's
say
brave
has
a
notion
of
a
tracing
object,
so
it
tracing
wraps
tracers
in
general
and
other
stuff.
D
So
what
I
have
to
do
for
this
to
work,
for
example,
grpc,
that
brave,
provides
a
grpc
tracing
object,
a
specific
one
right,
so
I
can
register
grpc
tracing
as
a
bean
and
what
grpc
tracing
requires
is
a
tracing
bin
which
is
common
for
the
whole
library.
So
let's
say
talking
about
the
auto
specifics.
That
could
be
that,
let's
let
us
assume
that
even
we've
taken
the
road
of
the
sleuth
api
that
then
it
translates
to
the
open,
telemetry
api
right.
D
It
doesn't
even
doesn't
really
matter
if
we
do
even
that,
then,
if
let's
say
auto,
provides
a
grpc
tracer
object.
That
requires
a
total
tracer
to
be
created.
That's
good
enough
for
me
because
I'm
going
to
set
up
say,
let's
say
some
sort
of
auto
configurations:
do
you
have
grpc
under
class
path?
Do
you
have
certain
properties
etc?
And
then
I'm
going
to
do
a
conditional
on
a
grpc,
instrumentation
library
right
and
that's
going
to
be
an
optional
dependency
as
well?
D
E
A
Yeah,
so
in
some
cases
we've
started
breaking
out
that
library,
instrumentation
and
it
is
in
that
kind
of
manner
where
it's
got
a
tracer
and
it's
got
sort
of
like
say
in
this
case
the
you
know
a
listener
or
something
that
you
have
to
register.
A
A
A
So
if
you
notice
actually
so
where
we
do
our
goal,
this
is
our.
This
is
sort
of
our
goal
for
all
the
instrumentations.
Is
we
have
the
java
agent
instrumentation?
We
have
library,
instrumentation
the
java
agent,
instrumentation
reuses,
the
library
instrumentation,
you
know
internally,
and
then
we
have
a
testing
module
that
ensures
that
both
of
them
do
the
exact
same
things.
A
So,
from
our
perspective,
if
you
know
that
that's
what
this
list
here
sort
of
helps
us
with
is
prioritizing
which
ones
of
these
we
should
break
out.
Additionally,
like
lettuce.
A
D
Good
idea
would
be
to
set
up
some
sort
of
a
standard
on
how
to
let's
say,
create
those
objects
or
like
if
your
various
classes
there.
If,
let's
say
one
of
them,
has
some
sort
of
a
builder
that
takes
in
the
auto
tracer,
and
so
that
would
be
really
useful.
This
is
how
it's
done
in
brave
and
I
really
enjoy
it.
D
So
if,
like
there's
a
common
naming
convention,
so,
for
example,
if
I
want
to
trace
jpc
there
is
a
grpc
tracing
object
with
a
static
factory
method
called
create
that
takes
in
some
sort
of
a
tracer
object,
because
there
are
different
tracer
objects
in
brave.
So
let's
go
don't
go
into
details
of
that,
but
it's
an
api
of
core
that
takes
in
right.
D
So
if
that
was
something
that
we
could
have,
that
would
be
really
great,
because
that
would
speed
things
up,
and
you
know
note
that
in
certain
cases
I
have
to
create
like
instantiate
this
in
the
via
the
constructor.
Sometimes
the
factory
method,
sometimes
something
else,
so
that
would
be
a
good
idea
to
standardize
this.
D
That's
a
very
good
question.
I
mean
I
don't
need
those
if
I
can't
make
things
glue
like
with
the
kind
things
that
we
have
right,
so
we
still
have
some
time.
What's
the
spencer,
what's
our
timeline
on
the.
E
Yeah
I
was
talking
about
this
with,
with
brian
yesterday,
brian's
the
spring
engineering
manager,
the
our
current
plan.
Oh
my
word,
it's
october
already,
it's
a
ga!
It's
been
september,
so
it's
been
two
months
away
after
spring
boot,
the
so
sometime
in
november.
C
E
Yeah
they're
currently
due
mid-november,
so
we
would
either
go
the
end
of
november
or
beginning
of
december,
so
we
can,
since
you're
you've
already
published
things
on
on
maven
central.
That's
that's
fine!.
A
Do
you
need
do
you
need
this
lit
whole
list
here
to
go?
Ga.
D
I
think
the
critical
one
is
the
logging
one,
that's
a
prerequisite,
because
without
this
people
will
not
be
able
to
correlate
logs
and
the
rest,
they
can
do
it
themselves
right.
If,
if
it's
like
in
between
our
release,
the
next,
you
know
release
right.
E
A
We
can
it
should
it's
supposed
it's
supposed
to
be
1.0
by
in
november.
Okay,.
E
E
A
There's
a
big
push
for
it
to
beat
ga
by
kubecon.
E
D
D
E
A
Okay
and
any
out
of
these
remaining
ones
any
is
there
one
that
would
be
most
helpful
for
us
to
do
that
you
could.
As
far
as
learn
you
know,
integrating
making
sure
that
all
the
whole
auto
configuration
story
works
well,
and
we
have
a
you
know,
standard.
D
Creation
pattern
that
you
like
big
grpc,
because
it's
it's,
let's
say
a
very
good
example
in
in
brave,
because
I
do
I
do
close
to
no
later
integration
work.
I
do
mostly
the
glue
or
the
auto
configuration
which
would
be
perfect
right.
C
A
D
E
D
A
We'll
go
a
couple
minutes
and
then
I'll
jump
down
to
weekly
digest
zero
nine
zero
release.
Next
week,
the
let's
see
we
don't
have
anybody
from
sdk
here
so
they're
going
to
release.
I
think
john
mentioned
going
to
release
on
monday
monday.
A
Okay,
tomorrow
or
monday,
we
will
target
so
I
pulled
just
these
three
so
far
I
targeted
like
specifically,
we
should
probably
get
into
zero
nine
that
metric
export
failure.
It
was
assigned
to
jakub.
C
Yeah
we
really
like
step.
We
really
would
like
to
have
this
reviews,
even
without
this
metric
expert
failed
fix,
because
because
some
customers
started
to
complain
about
this
implementation
not
found
exception,
so
what
we
did.
Apparently
we
suppress
logging
in
the
agent.
Yes,
and
if
you
suppress
login,
then
you
don't
see
this
exception,
so
it
works
fine,
but
still.
B
C
I
mean
please
already
look
around
because
right
now
for
tlp,
you
can
specify
that
it
will
be
only
tracer,
not
exporter,
with
stracia
yeah,
it's
power
power
power
submitted
pr,
so
yeah
a
tlp
can
be
without
utilities.
Yes,.
C
A
A
Okay,
let's
do
skip
skip,
skip
nut
here,
quick
update
from
last
week,
so
we
can
debug
pre-main,
I
updated
the
the
debugging
docs
it's
I
you
just
have
to
put
that
dash
agent
lib
first
before
the
dash
java
agent
and
then
the
debugger
is
loaded
before
the
pre-made,
so
our
docs
should
be
updated
shortly.
I
put
in
a
pr
for
that.
A
That
was
a
question
for
pablo.
Oh
tyler
anorak
wanted
to
mention
about
that.
The
mdc
copy
on
right
performance
that
you
had
brought
up
the
way
that
we're
doing
the
mdc
now
that,
under
the
that
it's
using
this
union
map
so
that
it
doesn't.
A
Have
that
copy
on
right
penalty,
okay,
cool
yeah,
something
else
all
right!
We've
got
three
minutes
left
so
just
quickly
weekly
digest
so
now,
there's
a
spi
for
vendors
to
provide
default
configurations
and
part
of
in
doing
in
adding
that
work,
the
we
mateish
and
it
refactored
the
config
well,
first
into
auto
value,
and
then
now
I
don't
even
is
it
still
auto
value?
It's
pretty
much
empty.
A
Now,
it's
just
a
property
bag
now
and
all
the
instrumentation
specific
properties
have
been
pushed
down
to
the
instrumentations
themselves
and
they
they
grab
and
then
cache
that
value
locally
to
reuse
it
so
that
that
actually
turned
out
really
nice
otlp
span
like
sergey
mentioned.
Support
is
supported.
A
Now
we
have
debugging
docs,
which
is
great
pavel,
had
added
these
and
pablo
also
added
the
high-level
muzzle
dock,
which
is
awesome
to
have
even
just
a
basic
explanation
of
muzzle
now
and
a
place
that
we
can
sort
of
launch
from.
As
far
as
adding
more
details,
we
updated
to
the
latest
sdk
snapshot,
which
brought
in
a
flood
of
good
changes.
A
One
of
the
changes,
actually
one
of
the
things
that
I
was
most
happy
about
is
the
span
set
parent
or
when
you
set
the
parent
on
the
spam
builder.
Now
it
only
takes
a
context
object
instead
of
a
span,
and
that
was
good
because
it
forced
there
were
still
like
five
or
so
places
where
we
were
only
propagating
the
parent
span
down
stream
and
so
that
basically
forced
us
to
fix
those
up
and
propagate
the
whole
context.
A
A
All
right,
so
deletion
party
coming
soon
yeah,
we
added
a
new
approver
mateosh,
has
been
doing
a
lot
of
great
and
tricky
work
in
the
repo
clearly
understands
a
lot
of
the.
What
what
what's
going
on
and.
A
And
we
removed
the
so
in
part
of
this
config.
One
of
the
things
that
fleshed
out
with
the
config
work
was
not
we're,
normalizing
that
the
not
needing
to
up
the
bytecode
hack
into
the
config,
and
so
we
were
able
to
unrave
removed
the
agent
specification
class
in
our
hierarchy.
A
A
And
we
have
four
minutes
left
any
last
questions,
thoughts.