►
From YouTube: 2022-06-15 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
E
C
C
I
had
a
chance
to
go
to
kubecon
in
valencia,
but
I
also
chose
to
not
go.
It
sounds
like
many
maintainers
didn't
go.
B
E
E
C
Updates
there
I'm
trying
to
push
everything
that
I
have
as
I
commit
it
right
now.
I
am
updating
the
http
test
integration
tests
to
use
that
as
a
case
for
testing
out
sending
of
metrics,
and
so
I'm
still
working
on
getting
that
infrastructure
working
with
this
pr.
It's
going
to
be
a
very
crude
first
pass
at
that
infrastructure,
and
then
I
want
to
follow
up
with
a
separate
pr
to
clean
up
the
way
we
can
set
up
the
metric
and
trace
tests.
C
E
I
have
one
question
chris
here:
does
this
going
to
cover
the
matrix
part?
Also
like
that
would
can
we
say
that
it
covers
the
kind
of
integration
test
for
the
metrics?
Also.
C
It's
going
to
cover
some
of
them,
so
I
think
with
this
pr,
I'm
going
to
restrict
it
to
the
tests
for
the
http
client
metrics,
as
well
as
the
asp.net
core
metrics.
But
it's
not
going
to
cover
the
the
classic
asp.net
metrics
good.
C
E
E
E
I
I
remember
what
I
bought
when
I'm
doing
this.
If
there
is
like
issues,
I
do,
I
think,
open
telemetry
sdk
repo
has
that
if
it
is
idle
for
a
few
like
weeks
or
some
time,
it
just
goes
and
closes
up
what.
So,
maybe
we
should
try
it
not
at
this
point
we
the
moment
when
we
have
a
like
very
number
of
issues.
E
So
there
were
like
many
tasks
last
week,
so
I
close
few
of
them
and
there's.
F
E
The
next
one
I
started
the
work
on
the
prometheus
exporter,
especially
this
one,
and
there
was
a
like
a
little
bigger
challenges
in
this
space.
The
reason
is,
the
prometheus
has
two
more
one:
two
one
for
the
asp.:
let's
go
to
the
prometheus
and
take
a
look
at
it.
What
I'm
trying
one.
E
So
that
makes
it
a
very
complex
for
us
to
integrate
that
yesterday
I
had
a
word
with
the
blanche
also,
so
the
very
simple
example
is
like
this
one
getting
started
with
the
prometheus.
E
I
started
my
work
and
then
I
was
blocked
on
this.
For
example,
if
we
look
at
it
here,
this
is
one
of
the
mode
in
the
http
listener.
We
can,
we
here
it
says,
add
prometheus
with
an
option
to
start
an
http
listener.
If
we
don't
have
this
and
do
just
an
ad
promote
yes,
it
does
not
send
data
at
all
actually-
and
I
just
checked
with
them
the
sdk
folks,
and
they
are
saying
it
is
mandate
to
have
this
if
we
are
using
a
console
application.
E
So
in
case,
if
we
are
planning
to
integrate
with
like
auto
instrumentation,
we
should
have
this
enabled
by
default
when
we
do
the
prometheus
with
the
http
listener,
one.
The
other
one
is
the
using
a
middleware
that
may
not
help
us,
because
we
are
hooking
up
in
a
startup
hook.
So
we
will
not
have
the
control
over
like
the
middleware
at
that
point
in
time.
So
the
only
option
for
us
to
use
this
at
this
this
functionality.
E
As
of
now
the
reason
why
I
was
interested
in
prometheus
is
it
could
make
our
integration
tests
a
lot
more
easier.
E
Instead
of
having
a
mock
exporters,
we
can
directly
have
in
prometheus
like
container
spawned
up
and
listening
on
our
metrics,
and
we
have
an
apa
where
we
can
read
whether
that
matrix
was
sent
or
not.
So
it
makes
our
life
a
lot
more
easier
with
that.
So
that
was
the
like
idea
behind
me
starting
this
work,
but
if
we
agree
to
have
only
the
http
listener
part,
we
can
move
with
this
approach.
And
again
I
see
a
work
from
the
chris
on
the
otlp
part
like
if
that
is
going
to
address
our
need.
E
We
can
still
move
this
work
to
a
later
point,
because
prometheus
exporter
in
sdk
is
going
through
a
big
change.
It's
going
to
get
the
split
as
twitter
mentioned
yesterday,
so
we
can
keep
this
on
hold
and
take
a
look
at
the
other
test
and
how
it
could
help
us
move
forward.
D
D
E
You
are
exactly
right.
The
reason
is
it
especially
has
a
problem
with
windows
whenever
we
start
an
http
listener.
The
reason
is,
it
requires
a
specific
set
of
permissions
at
the
http
cis
layer.
So
that's
the
reason
why
the
http
listener
is
is
not
the
recommended
thing
to
use
in
the
like
asp.net
core,
but
what
I
heard
in
asp.net
by
default,
the
http
listener
is
enabled
for
prometheus.
That's
what
I
heard
in
the
open,
telemetry
sdk
implementation
it
has
is
enabled,
but
I
I
don't
like
know
with
our
current
design.
E
We
will
be
able
to
take
and
use
that
middleware,
even
if
we
take
and
use
that
middleware.
That
would
be
for
only
for
the
like
the
web
scenarios.
If,
if
we
want
to
like
collect
telemetry
from
like
like
a
console
or
a
windows
based
application,
we
won't
be
able
to
do
it
with
that
middleware.
So
we'll
still
need
an
http
listener.
D
B
C
C
E
E
I
did
not
figure
out
a
certain
space
that
where
it
could
break
that's
why
I
feel
that
adding
a
prometheus
without
a
proper
research
from
our
end
is
not
the
right
thing
to
do
so
it
is
going
to
or
like
take
a
lot
of
time.
The
adding
it
is
super
easy,
like
adding
a
one
line
of
code
in
our
project,
but
without
understanding
what
is
the
impact
that
is
going
to
bring?
I
think
we
should
hold
on
to
this
work
for
the
next
release.
We
should
not
like
move
faster
towards
this
part.
B
C
Only
other
comment
regarding
this:
you
had
mentioned
potentially
using
the
exporter
to
help
with
testing
in
one
sense
yeah.
It
can
simplify
the
testing
just
because
it
it
flattens
the
data
a
lot,
whereas,
if
we're
validating
data,
that's
transmitted
over
otlp,
the
data
is
a
lot
more
hierarchical
and.
E
Or
we
can
have
something
like
this
for
the
time
being
with
the
http
listener,
and
we
can
try
and
understand
what
are
the
challenges
we
are
facing
with
the
like
community
as
it's
in
beta.
It
is
also
good
to
take
that
risk.
Also.
So,
if
we
agree
on
it,
I
can
I
have
everything
ready.
I
could
send
up
here
on
this
path.
E
D
F
F
C
C
Exactly,
whereas
with
zipkin
that
data
gets
flattened
down
and
some
things
don't
map
over,
not
that
we're
necessarily
validating
those
things,
but
it
it
really
it
it's
part
of
it.
Similarly,
with
prometheus,
you've
got
that
flattened
nature
of
the
data.
C
The
nice
thing
about
testing
prometheus
is
you:
don't
have
to
spin
up
a
separate
listener
in
the
tests,
but
you
do
have
to
make
the
http
call
to
get
the
data.
E
E
C
So
I
forget,
which
date
we
picked.
I
think
it's,
the
21st.
E
C
C
F
C
But
still
yes,
I
mean,
if
we
bumped
it
out
a
week.
I
don't
I
don't
know
if
that's
gonna
be
enough
time
and
then
the
following
week
is
a
u.s
holiday,
so
that
at
least
affects
a
handful
of
us.
E
B
F
F
F
Okay,
so
today
with
rasmus,
we
were
looking
together
with
on
the
activity,
listeners
code
and
basically
the
activity
api.
And
then
we
made
a
one
step.
Rasmus
meet
a
one
step
back
and
checked
what
why
we
need
the
reference
to
ask
net
core
in
the
estimate
instrumentation,
and
we
realized
that,
like
90,
we
can
remove
the
reference
to
asp.net
core
from
the
from
the
aspen
instrumentation,
and
then
we
will
not
have
the
problem
basically
they're
using
just.
It
looks
like
that.
F
The
reference
is
only
to
do
some
reflection
and
just
not
to
create
a
dto
type.
Probably
we
can
create
a
dto
type
to
http
context,
http
request,
because
this
is
what
the
object
is
sent
in
the
activity
as
the
sender
or
things
like
that.
So
when
you're
sending
activity
they're
putting
the
http
contacts-
and
they
are
just
in
the
auto
instrument
in
the
instrumentation
sdk-
they
are
just
using
reflection
to
like
rebuild
the
structure
and
we
can
just
create
a
one
to
a
dto
for
it
and
it
should.
F
And
then,
if
we
do
it,
we
can
just
probably
enable
all
instrumentations
by
default,
because
basically
that
was
the
problem
that
the
console
application
didn't
have
the
reference
to
the
aspnet
and
that's
what
we
will
probably
try
doing
erasmus.
Am
I
correct
or
or
was
it
somehow
clear
or
should
I
show
the
code.
A
F
A
C
C
F
B
F
C
That
feels
like
some
specific
approaches
to
minimize
some
of
the
problems,
but
then
it
looks
like
you've
got
some
other
general
things
that
you
experimented
with
that
are
worth
talking
about.
F
A
F
C
Right
so
I
mean
that's
a
decision
we're
gonna
have
to
make,
because
I
feel
like
that.
Il
rewriting
allows
the
automatic
loading
in
a
sense,
because
I
mean
we
can
register
the
activity
source
name
as
one
that
needs
to
be
listened
to,
but
that
won't
actually
do
anything
if
the
instrumentation
library
never
loads.
C
F
F
C
C
Yeah
I
mean
the
whole
goal
of
being
able
to
autoload
everything
was
to
remove
the
need
of
having
somebody
to
explicitly
call
out
which
instrumentation
libraries
to
have
enabled.
C
My
only
concern
there
is,
if
we
enable
all
sources,
but
then
some
of
those
sources
have
a
problem
loading
like
they
have
a
hard
dependency
on
some
type
being
available.
When
you
load
them,
then
that
could
cause
problems.
C
Okay,
so
system.source
when
you're
writing
to
the
so,
let's
say:
you're
writing,
instrumentation
in
your
library
and
you're
writing
directly
to
diagnostic
source.
You
have
the
ability
to
attach
arbitrary
data
to
your
your
thing
and
so
you're,
using
a
concrete
type
to
to
write
to
that
diagnostic
source.
Now,
in
the
listener,
on
the
listener
side,
that's
where
you're
likely
going
to
be
reading
that
data,
and
so
in
that
part
of
the
instrumentation,
where
you're
reading
that
data
and
you're
now
converting
that
reference
into
a
concrete
type
from
that
library.
F
F
Fetcher,
so
this
is
the
type
which
is
responsible
for
so
there
is
this
onstart
activity,
and
here
we
are
getting
this
payload,
which
you
are
referring
to
chris
right.
This
is
like
the
payload,
and
this
is
an
http
context,
and
we-
and
here
is
this
implementation,
which
extracts
like
the
the
data
from
the
payloads
to
an
http
context,
but
basically,
as
far
as
remember
this
contact
dispatcher
is
just
using
reflection
to
where
you
can
see
property
fetcher.
F
So
basically,
just
a
reflection
to
just
you
know,
load
the
data.
It
could
be
a
dto,
it
doesn't
have
to
be
a
reference.
To
be
honest,
I
think
using
that
way,
yeah
that's
a
fancier
way
of.
C
C
Now
with
that
being
said,
I
think
that's
going
to
be
a
common
pattern
with
instrumentation
libraries
that
in
that
they're
going
to
be
relying
on
those
concrete
types.
C
I've
seen
that
as
a
very
common
pattern
with
activity
source,
I
honestly
have
less
experience
with
interacting
with
that
instrumentation.
So
I
don't
know
if
there's
still
dependencies
on
the
concrete
types
there,
but
I
know
for
diagnostic
source.
C
I
mean
I
can
definitely
be
wrong
about
it,
and
so
I
see
see
value
in
in
both
things.
C
So
let's
say
we
tackle
or
that
that
asp.net
core
instrumentation
is
rewritten.
The
http
client
instrumentation
is
rewritten,
so
so
all
of
those
that
are
relying
on
diagnostic
source
gets
rewritten
to
remove
the
concrete
dependencies.
C
C
Then
that
still
leaves
all
of
the
instrumentation
libraries
that
are
defined
in
contrib
and
third-party
repos.
C
C
And
so
that's
where
my
concerns
increase.
C
Because
I
think,
if
instrumentation
is
enabled
automatically,
there
will
likely
be
a
perception
that
oh,
I
can
just
go
and
download
this
instrumentation
from
this
other
source
drop
it
in
some
sort
of
plugins
or
instrumentations
folder
in
in
the
install,
and
then
things
will
just
work
like
magic.
F
The
problem
is
that
the
runtime
part,
the
problem
is
that
one
it
will
not
work
for
current.net,
right
versions,
right.
A
But
dotnet,
but
they
are
probably
going
to
release
the
system
diagnostic
7
package,
so
it
will
work
with
the
6th
version.
But
then
again
we
have
a
problem
with
the
versioning,
because
if
six
will
be
the
major
and
then
we
are
referencing
the
version,
seven
system
diagnostics,
the
second.
F
Mighty
issue,
but
still
erasmus.
I
think
it
will
be
the
similar
problem
with
the
race
condition
when
it
will
be
changing
right.
You
still
have
this
problem
when
you
are
detaching
a
listener,
creating
a
new
listener
that
there
can
be
some
activities
in
between
which
are
held
by
the
new
and
old
like
listener.
Exactly.
A
F
A
No,
it's
not
complicating,
because
you
still
have
one
instance,
but
until
it's
enumerating
all
the
available
listeners
and
sources,
then
that's
that
time
you
might
have
an
activity
from
the
library
you
just
loaded
and
this
is
going
to
be
lost
and
definitely.
C
So
I
can
see
how
the
race
conditions
could
occur,
but
in
practice
I
wonder
how
likely
they
would
actually
be
because
you're
talking
about
doing
this
when
an
assembly
first
loads
and
how
likely
do
we
think
either
span
data
or
metric
data
or
log
data
would
start
flowing
like
really
soon
after
the
assembly
loads.
A
F
What's
happening
when
there's
an
assembly
load
when
there
are
two
threads
in
power
that
won't
load
the
same
assembly,
the
second
is
blocked,
is
blocking
all
the
threads
or
how
does
it
work
or
you
don't
know,
I'm
concerned?
If
you
I
have
like
two
parallel,
you
know
calls
and
both
of
them
are
calling,
for
example,
http
client,
and
should
we
like
synchronize
them,
or
you
know
the
http,
this
load,
this
loading
and
stuff
like
that
or
we
don't
need
to.
C
And
so
it's
kind
of
like
static
classes,
loading
like
the
the
runtime
itself,
I
think,
enforces
a
lock.
F
Yeah,
I'm
just
thinking
if,
but
probably
they
are
synchronized.
If
there
are,
you
know
in
parallel,
multiple
assembly,
loads
for
different
libraries
etc,
and
how
would
it
work
that,
for
example,
one
thread?
Will
you
know,
load,
http,
client,
second
and
npg,
sql
or
stuff
like
that,
just
to
make
sure
that
we
are
not
losing
any
subscription
that,
for
example,
oh,
we
have
just
you
know,
enabled
the
sp-
that's
not
instrumentation,
oh,
but
this
thread
just
enabled
and
as
well
and
we
lost
the
previous
one.
I'm
afraid
of
such
things.
F
A
The
yeah
this
might
be,
but
definitely
this
needs
a
lot
of
refactoring
is
like,
of
course,
yeah.
The
activity
listener
has
lots
of
action
properties.
This
can
be
made
like
static,
so
they
are
like
just
reassigned
to
the
instance.
A
Yeah
the
current
disposing
implementation
is
also
weighed.
Actually,
you
can
call
this
pose
and
reuse
the
instance,
but
this
will
be
tricky.
A
There
might
be
another
option
that
I'm
currently
experimenting
with.
This
is
using
x
expression,
trees
to
fix
the
should
listen
to
property.
F
A
Not
really,
there
is
a
basically
if
you
are
attaching
the
listener.
There
is
a
part
of
the
code
that
re-enumerates
the
either
the
sources
or
the
listeners.
A
I
think
it
was
sources
and
this
part
is
not
publicly
accessible.