►
From YouTube: 2023-02-01 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
A
A
B
Well,
I
suppose
we
can
get
started.
I
think
say
that.
C
A
B
Mike
has
succeeded,
we're
on
the
path
of
Glory.
We
right.
We've
landed
all
the
the
DI
stuff,
including
the
package
rename
correct,
Mike,
yep,
sweet,
so
I
think
the
plan
will
be
that
we
release
another
RC.
B
B
B
B
Path
to
glory
and
then
I
think
we'll
let
it
simmer
for
about
two
weeks
and
then
hopefully,
if
all
else
goes
well,
then
we'll
do
the
real
one
for
release
once
and
for
all,
and
Mike
proposed
Valentine's
Day,
so
it'll
be
a
lovely
release.
B
Oh
and
I
think
the
other
thing
CJ
mentioned
was
that
that
could
also
give
us
some
time
then
to
bring
the
DI
options.
Config
patterns
to
all
of
the
various
things
within
the
contrib
repo.
So
I
don't
know
who
will
take
on
that
work
necessarily,
but
that
is
probably
not
a
huge
amount
of
work,
so
that's
exciting
anything
else
to
say
Mike
or
others
regarding
that
or
questions.
A
A
B
B
D
E
Retry
is
actually
part
of
the
spec
and
then
persisting
is
not,
but
something
that
we
still
want
to
add
for
reliability's
sake,
and
this
is
just
kind
of
giving
some
context
and
like
a
plan
on
how
I'm
going
to
be
adding
that
in
the
next
couple
weeks
here
so
far,
I
I'm
thinking
of
just
adding
for
one
or
adding
the
retry
and
the
persist
for
like
one
of
the
the
options
in
that
table
there,
like
maybe
like
traces
over
like
HTTP
or
something
and
then
see
how
that
goes,
to
make
adding
all
the
other
ones
a
faster
process.
E
Yeah
I
think
there
were
also
some
some
comments
on
this
issue.
If
anybody
wants
to
go
into
more
detail
about
that,
but
so
far
there's
just
one
PR
that
I'm
currently
doing
a
little
bit
of
changes
with
to
make
it
use
dependency
injection
rather
than
blowing
up
the
the
options,
object
and
adding
like
a
whole
bunch
of
new
fields.
To
that.
B
B
Would
it
ever
make
sense,
or
have
you
thought
about
it,
whether
it
would
make
sense
for
the
persistent
storage
to
be
possible
to
be
independent
from
like
the
retrievable
errors
for
the
spec,
like
I'm,
I
I,
don't
know
exactly
what
kind
of
a
use
case
it
may
be
but
like
if
somebody
just
simply
wanted
to
save
stuff
off
the
disk,
for
whatever
reason,
regardless
of
specific
error
code,
if
it
failed
to
be
sent
to
a
back
end,
is
there
any
value
in
making
it
more
broader,
more
flexible
in
that
regard
or.
B
B
Like,
let's
say
one
of
one
of
the
things
the
persistent
storage
is
meant
to
satisfy,
or
one
use
case
is,
if,
like.
B
So
presumably
like,
if,
if
there
has
been
anything,
that's
been
written
to
disk,
then
the
next
time
that
that
service
spins
up
then
that
data
can
still
be
retried.
Yes,.
E
B
E
B
That
so
I
mean
like
that
kind
of
scenario
is
not
necessarily
captured
in
this,
like
retriable
error
type
of
thing,
because
I'm
not
in
that
scenario
you're
not
actually
getting
like
a
response
code.
True.
E
Yeah
you're
just
like
if
I
guess
the
program
gets
like
a
shutdown
signal,
then
it'll.
Try
writing
it'll.
First,
try!
Writing
all
the
all
like
the
current
things
that
we're
ready
getting
ready
to
send
to
disk
then
like
try
to
send
it,
but
maybe
it
won't
send
it
all
or
any
of
it.
So
yeah.
C
I
think
you,
you
asked
like
made
a
comment
on
this
regarding
specifically
about
the
retries,
so
just
wanted
to
like
clarify
a
little
bit
on
that
I.
Think
this
part
doesn't
involve
the
other
retries
which
are
part
of
the
spec
and
the
one
that
I
think
Michael
has
was
working
on
before
I
think
we,
we
should
still
do
that,
because,
obviously
it's
part
of
the
spec
and
this
part
is
kind
of
not
dependent
on
it.
C
So
for
this
one
to
work
like
ultimately,
whatever
the
failure
code
is
like
after
the
retries
will
still
go
ahead
and
store
it
so
like,
let's
say
after
10
retries,
if
you're
still
failing
we'll
just
go
ahead
and
save
the
Telemetry
to
the
disk,
so
yeah
that
that
part
is
kind
of
little
bit
independent
of
this
work.
E
A
A
F
E
It
was
adding
retries
to
grpc
for
this
exporter,
I.
A
B
Right
this
is
this
is
speaking
to
you're,
just
using
the
like
setting
up
for
grpc
like
a
retry
policy
yeah-
and
this
is
independent
of
the
of
the
persistent
storage
stuff.
C
Yeah
also
like
just
a
comment
on
this
one
I
think
we
may
need
to
take
a
look
at
this
like
I'm,
not
sure,
like
I,
think
this
just
blocks
the
exporter
thread
until
all
the
retries
are
done.
C
So
we
we
may
need
to
consider
this
as
well
to
see
like
if
how
to
make
it
like
if
there
is
any
way
to
make
it
more
efficient,
because
it
could
be
that
we
are
retrying.
But
then
the
the
bat
starts
filling
in
and
like
we
start
dropping
the
10
battery,
so
I
I
haven't
actually
tried
that,
but
I
was
thinking
that
could
be
a
possibility
here.
B
A
retry
happens
behind
the
scenes,
whatever
the
the
grpc,
client
or
HTTP
client
is,
is
retrying,
and
with
this
exponential
back
off
that
that
could
be
a
potentially
large
yeah
amount
of
time
that
the
export
is
is
occurring.
B
B
C
Case
scenario
also,
we
have
something
called
the
deadline
in
the
otlp
itself.
I
think
we
said,
like
a
deadline
that
I
remember,
seeing
that
that's
another
I
think
if
the
deadline
exceeds
it's
just
like
cancels
the
request,
if
I
remember
that
correctly,
so
there
was
that
another
factor
in
there
yeah.
C
B
Yeah
yeah,
needless
to
say,
yeah,
should
vet
out
and
ensure
that
that
works
as
we
think
it
does
but
I.
But
based
off
of
that,
you
have
that
deadline
thing.
It
seems,
then,
that
there's
a
good
potential
that.
C
Yep
yeah
and
like
because
it
could
be
handled
like
this
is
like
a
separate
work
item
we
can
take
on
and
work
on
this
as
well.
Do
it
I
mean
this?
C
Definitely
we
we
have
to
do
this
with
this
part
of
the
spec
for
sure
so
and
also
like
I
think
you
asked
I
just
saw
like
you
asked
a
question
like
if
there
is
any
spec
work
going
on
like
I'm,
not
aware
of
if
there
is
any
spec
proposal
related
to
the
persistent
storage
ongoing
I
I,
just
like
in
my
comment,
I
think
I
I
might
have
confused
you,
but
I
just
meant
like.
C
B
So
like
this
is
this
PR
is
basically
like
you
know:
retry
independent
of
persistent
storage
I
was
actually
kind
of
asking
like
the
reverse
question
like
is
there
ever
a
time
when
we
might
want
persistent
storage,
irrespective
of
this
specific
set
of
like
spect
retry
stuff,
so
like
export
fails
for
some
other
reason
that
might
might
not
be
specs
like
system
crash
is
one
but
like
I'm
imagining
another
one
like
it
doesn't
look
like
authentication
failure
is,
is
one
of
the
retrievable
status
codes
I?
E
E
It
could
be
like
made
in
a
way
that,
like
leads
to
like
the
possibility
of
opening
up
the
like
API
to
users
like
in
the
future,
but
I
don't
know
if
that's
the
like
the
initial
thing
that
we're
gonna
try
to
add
like
we
could
have
a
function.
That's
like
is
or
like
should
save
the
storage
and.
A
B
B
That
that's
that's
a
brings
up.
Another
question,
the
retryable
part,
so
independent
of
the
persistent
storage
were
you
thinking
of
making
that
opt-in
as
well
or
that's
just
going
to
be
like
default.
Behavior
I.
E
Believe
that
is
default
behavior
in
the
spec
I
haven't
looked
at
that
one
recently
been
more
focused
on
the
retry,
but
I
think
that's
part
of
the
spec.
Do
you
recall
a
bishwash.
C
A
A
B
C
B
Foreign
yeah,
this
spec
basically
just
says,
needs
to
retry,
but
it
doesn't
specify
exactly
the
strategy
other
than
you
know.
Things
like
exponential
backup
and
with.
E
Yes,
there's
that
30-second
export
time
limit
and
then
the
what
was
it
the
deadline.
The
bishwish
was
talking
about
other
other
people,
timing,
things
that
would
need
to
be
taken
into
account,
which
may
be
the
Java
Sig
was
like
knew
all
about
those
or
kind
of
interesting
to
to
message
them
about
their
choices,
or
maybe
they
have
like
some
issue
that
just
has
all
the
discussion
about
their
choices
for
picking
those
values.
E
B
Yeah
I,
don't
recall
myself,
the
other
thing
I,
don't
recall
is
if
so,
Java
obviously
has
implemented
retry,
but
I
don't
recall
if
they
decided
to
enable
it
by
default
or
if
there
was
something.
If
I
remember
right,
there
was
something
about
like
some
hidden
setting
because
because
they
had
just
basically
adopted
settings
that
I
think
were
informed.
Somehow
I
don't
remember
how
they
came
to
these
these
figures,
but
they
just
adopted
them
in.
B
We
would
that
the
spec
would
actually
adopt
specific.
You
know
things
in
regards
to
like
Max
attempts
and
back
off
and
and
so
on,
but
that
never
happened.
A
B
A
B
E
B
Cool,
thank
you.
So
what
else
we
got?
We've
got
a
number
of
PR's
to
go
through.
Let
me
close
some
tabs.
C
Yeah
I,
just
added
them
I,
think
yeah.
Those
pairs
are
just
opened
since
last
few
days,
so
just
wanted
to
bring
this
up
and
see
if
we
can
get
a
review
on
them.
C
Actually,
I
I
had
a
quick
question
on
this
one,
particularly
so
I
think
we
we
have.
We
have
already
added
the
enrich
and
filter
on
espnet
core
we're
trying
to
do
the
same
in
the
HTTP.
One
I
think
we
need
to
like
for
the
signature
wise,
if,
like
URL
or
not,
anyone
can
take
a
look
at
this
and
see
if
I
think
I
have
added
a
comment
somewhere.
C
If
you
scroll
down
things,
he
just
started
reviewing
it
and
I
added
that
yep,
so
I
believe
we
need
to
pass
in
the
request
and
response
both
and
have
that
as
a
signature.
Instead
of
just
passing
in
the
response,
because
I
just
found
an
issue
where
we
don't
report
the
metric
at
all.
C
If
there
was
a
network
failure,
because
the
response
itself
is
null
and
like
me,
since
we
entirely
rely
on
response
to
get
all
those
property
tags,
then
like
we
don't
report
that
so
I
I
have
created
a
PR
to
fix
that.
So
this
needs
to
be
reviewed
first.
If
this,
if
this
looks
good,
then
we
can
come
back
to
that
other
one
and
get
that
changed
as
well.
So
that's
why
the
guy
just
added
this?
Yes,
all
together.
B
Gotcha
so
you're
saying
basically
like
if
a
request
gets
aborted
for
some
reason.
Basically,
you
don't
get
a
response
right.
We
still
need
to.
It
would
be
ideal
if
we
still
had
a
hook
that
called
enrich,
but
at
least
with
a
request
that
makes
sense.
Yeah.
C
So
yeah,
it's
like
these
two
PRS
are
kind
of
related.
It's
just
like.
If
we
can
get
the
first
one
figure
out
like
get
this
much
so
I
think
I
can
get
like
the
I
can
work
on
reviewing
the
second
one
and
get
that
to
get
that
ready
for
the
merging.
B
C
C
Yeah,
this
I
think
we
have
like
bunch
of
issues
that
were
reported
where
we
don't
add
the
HTTP
route,
the
template
on
the
activity,
because
some
sometimes
like
the
the
users
are
not
using
the
the
MVC
they're
just
using
like
the
minimal
API
way.
C
So
if
they
are
doing
that,
the
the
event
that
we
rely
on
to
get
the
HTTP
route
itself
is
not
triggered
the
diagnostic
Source
event,
and
when
that
happens,
they
they
see
the
activity
name
as
like
the
the
actual
URL
which
which
is
like
high
cardinality,
and
it's
pretty
much
not
very
useful
for
them
or
to
group
those
operations.
C
So
I
have
created
two
so
first
test,
especially
like
the
just
the
unit
test
to
show
like
we
what
customers
are
reporting
is
true.
The
second
one
is
an
attempt
to
fix
that.
C
However,
I'm
not
sure
if
that
covers
all
the
cases
of
asp.net
code
or
not
so
I,
think
like
somebody
who
knows
much
about
the
asp.net
core,
like
the
different
flavors
of
it,
I
think
I'll
need
some
help
with
getting
that
reviewed
and
if
that
fix,
looks
good
I
think
we
we
may
be
able
to
close
bunch
of
issues
reported
by
customers.
D
C
C
C
It's
it's
still
in
draft,
actually
fix
yeah
the
one
below
I
think
you
had
it's
right
in
the
middle.
If
you
see
right
there,
yep
yep.
B
C
C
B
B
C
D
That's
a
good
question:
I'd
have
to
go
look
at
it,
it's
kind
of
been
a
while,
since
I
looked
at
the
route
template
stuff.
So
let
me
spend
a
little
time
on
this
and
I'll
get
back
to
you
sure.
B
Yeah,
my
memory
is
fuzzy
on
this
is
well
I've
dealt
with
some
of
this
actually
in
the
New
Relic
agent.
In
the
past,
we
have
well
the.
B
Totally
works
differently
from
otel's
instrumentation.
We
it's
method-based
instrumentation
that,
like
bytecode
injection,
injects
itself
into
various
different
methods
as
they're
being
executed
so
like
in
the
in
the
web
framework
stack
asp.net
core,
like
asp.net,
like
classic.
Whatever
each
stack
has
like
you
know,
a.
E
B
Pipeline
and
at
different
points
in
the
pipeline,
like
you,
have
a
little
more
information
about
the
the
end
point
that's
getting
hit
like
at
the
beginning
of
the
pipeline.
You
know
you
don't
necessarily
have
the
route
information
you
just
have
the
URL
and
so
like.
We
do
a
thing
where
we
set
the
set
the
name
of
the
we
call
it
a
transaction,
but
you
can
kind
of
think
of
it
as
a
similarly
to
like
a
span.
B
We
set
it
to
that
but
like
as
we
hit
further
points
down
the
pipeline
we
take
on
like
we
have
this
naming
priority
type
of
thing
so
we'll
like
take
names
that
are
better
cardinality,
maybe
more
descriptive
of
the
endpoint
like
the
like
the
route,
and
so
this
is
kind
of
similar
to
that.
B
I
don't
know
if
it
needs
to
be
as
complex
as
that,
but
I
I
I
just
know
that
there's
there
is
some
complexity
here
and
and
lots
of
different
flavors
of
like
how
far
the
request
makes
it
down
the
pipeline
or
or
not.
C
Yeah
this
this
has
been
reported
multiple
times
and,
like
I
mean
the
other,
the
other
issue
to
that
is
like
when
we
don't
actually
report
that
HTTP
route,
it's
like
we,
we
are
not
complying
with
the
spec
also,
even
though
it
is
available.
So
that's
like
another
issue,
but
yeah
I
think
like
some
of
these
issues
are
the
ones
that
we
will
will
need
to
fix
before
we,
you
know,
look
into
stabilizing
the
instrumentation
libraries
I
think
we
were
looking
into
releasing
that
as
like
0.5
or
some
version.
C
B
Okay,
was
this
one
on
the
agenda
as
well?
Oh
yeah,
it.
F
Was
I
added
that
hello,
so
yeah
when
I
was
trippersing
through
the
open
issues,
I
found
the
patient
number
2513
and
that
issues
suggested
that
we
may
be
able
to
automate
at
some
of
the
CI
tests,
specifically
on
Direct
safety
and
I,
found
that
if
you
scroll
down
a
little
bit
the
link
to
Coyote
yeah.
B
F
Quite
an
interesting
framework
and
gave
it
a
try,
so
I
think
you
probably
buy
three
to
five
minutes.
If
people
have
time
to
go
on
one
of
the
example
of
how
coyote
works.
A
F
Oh
I
was
saying
that
I
can
probably
screen
share.
I
can
probably
take
three
to
five
minutes
to
screen
share
how
coyote
works.
If
people
have
time.
F
Okay,
so
basically,
how
coyote
works
is
that
it's
kind
of
rewriting
the
binaries
a
the
binaries
of
the
project,
and
then
it
will
have
some
specific
combinations
of
threading
thread,
specific
tasks
that
will
exercise
all
possible
sequences.
F
So
this
is
the
test
of
that
will
expose
a
deadlock,
so
how
it
basically
does
is
that
there
will
be
reader
and
writer
on
a
buffer
and
then
show
for
the
reader.
It
will
try
to
take
before
exercise
while
exercising
on
the
buffer.
It
will
take
a
long
on
the
this
dot
sync
object,
so
that
would
potentially
run
into
a
deadlock
situation.
F
After
the
we
built
the
project
we
can
so
before
running
coyote
rewrite
we
will
have
to
install
coyote
CLI,
which
is
one
command
only
so
I
think
that's
that
can
be
easily
done
through
the
CI
workflow.
So
after
installing
the
coyote
CLI,
we
can
use
command
line
to
rewrite
the
as
binaries.
F
So
right
now
we
see
that
yeah
I've
already
Rewritten
it.
So
it's
saying
that
the
assembly
is
already
written
with
matching
signature,
so
after
that
we
can
use
the
coyote
test
to
so
this
is
the
the
argument.
Is
the
method
name
that
we
want
to
run
and
then
this
just
how
many
iterations?
So
this
is
the
100
iterations
and
then
we
will
have
some
text
and
traces
on.
F
A
F
So
this
is
the
test
output
we
have
brand
and
this
is
the
sequence
of
decisions,
so
the
actions
in
nature,
the
buffer
that
results
in
the
deadlock
situation.
F
Trains
will
have
traces
for
that
as
well,
which
supposed
to
be
easy
for
us
to
debug
so
yeah,
that's,
basically
how
it
works,
so
we
already
have
some
existing
as
metrics.
That
would
have
that.
That's
meant
to
test
the
threat.
Safety
issue
and
coyote
has
integration
with
X
unit
as
well,
but
it
doesn't
really
work
well
with
the
theory,
because
it's
not
currently
supporting
method
groups,
but
it
works
well
with
fact.
So
we
may.
F
If
we
want
to
build
the
test
on
top
of
coyote,
they
have
to
think
about
existing
tests
a
little
bit
so
yeah,
sorry,
a
lot
of
talking
and
then
I
made
a
small
PR
or
during
that
how
that
works
and
yeah
just
wanted
to
you
know
people
feel
about
it.
B
Cool,
that's
pretty
exciting.
The
in
addition
to
like
deadlock
scenarios
can
it
test?
Is
there
a
way
to
test
like
exclusive
access
or
violations
of
like
exclusive
access
to
shared
memory?.
F
I'm
not
sure
about
that
specific
scenario:
exclusive
access.
But
if
you
go
to
the
coyote
sample
somewhere,
foreign.
F
So
these
are
sorry.
Can
you
see
my
browser
now
yep?
So
these
are
the
scenarios
that
we
can
coyote
supports.
Now
I
haven't
had
a
chance
to
go
through
every
scenario
myself
well.
F
Holistic
view
of
what
it
supports
now,
but
I
can
go
through
each
sample
from
what
it
supports
and
what
it
doesn't
support,
but
I
think
one
of
the
way
to
figure
that
out
is
that
when
you
do
coyote
rewrite
it
has
the
parameter
that
you
can
pass
it
to
compare
the
binaries
before
and
after
rewriting,
and
that,
if
there's
a
difference
in
that,
that's.
B
Yeah,
this
is
great.
The
the
one
of
the
scenarios
that
I
never
one
issue,
that
I
think
utkarsh
fixed
within
the
last
number
of
months,
was
a
Threading
problem
with
metric
aggregation,
specifically.
B
Where
we
were
using
effectively,
two
different
lock
constructs
in
two
different
places
and
I'd
wonder
if
how
we
could
write
a
test
if
we
could
write
a
test
using
coyote
to
have
caught
that
problem
and
what
that
would
look
like.
F
I
think
we
can
just
write
it
normal
executing
tests
and
just
we
can
put
those
tests
that
specifically
as
testing
thread
safety
in
the
project
and
then
add
that
to
the
workflows
of
GitHub
when
we
are
building,
we
are
running
CI,
that's
my
current
thinking.
F
So
could
you
ping
me
the
full
review
good
question
made
on
that
I
wanted
to
learn
more
about
it.