►
From YouTube: 2022-07-06 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
D
D
F
A
Okay,
I
opened
like
everything
little
earlier
in
the
tabs
over
here.
So
here
are
the
three
pending
pull
requests.
Erasmus,
do
you
want
to
first
speak
about
this
because
it's
going
to
take
a
little
longer
time,
the
other
one
should
be
short.
I
think.
C
Yeah,
I
actually
added
the
schema
about
which
part
this
this
pr
is
about.
I
hope
this
one
simplifies.
C
Yeah,
so
everybody
can
understand
a
little
bit
better
how
what
is
going
on
there.
A
So
yesterday
I,
like,
I
left
a
comment.
The
look
like
the
overalls
like
up
the
strategy
or
something
is
good,
but
the
implementation
wise.
I
feel
there
are
a
lot
of
missing
pieces.
For
example,
if
I
comment
out
the
event
handler
still,
the
asp.net
tracing
gets
captured,
it's
not
happening
through
the
the
instrumentation,
rather
than
that
it
it
treats
it
as
a
like
a
custom
source
and
starts
collecting
the
information.
A
So
we
should
have
a
way
to
avoid
that,
because
that
might
give
us
a
lot
of
information
like
where
customers
may
not
like
it,
because
it
will
have
very
less
information,
if
I
remember
correctly
in
open,
telemetry
sdk,
they
beautify
that
span
to
look
properly
and
give
the
lot
of
information
in
it.
A
That's
the
one
thing
I
noticed.
The
second
thing
is
like
I
just
want
to
check
like
if,
if
you
want
to
use
an
even
brush.
A
So
what
I'm
seeing
is
like
I
added
like
I
up
the
code
over
here.
So
let's
look
at
what
changes
I
did
here
if.
A
D
Blur,
yes,
so
then
you
you
have
seen
without
this,
this
hotel
this,
this
processing
right,
yeah.
A
So
still
the
spans
are
getting
collected,
and
but
it
is
not
using
the
instrumentation
in
this
way,
and
also
I
see
we
are
having
a
detector
for
everything.
So
we
have
a
very
like
small
smoke
project
here,
which
does
like
a
http
client
call.
So
I
have
these
things
updated
here.
I
don't
have
like
the
traces
to
connect
http
client,
but
if
I
execute
this
one
it
starts
collecting.
A
A
A
So
I
I
see
some
flaw
like
we.
This
should
not
happen.
If
we
have
a
detector
support,
everything
should
come
through
the
director
support.
So
these
are
the
few
things
I
noticed.
Maybe
the
pr
is
also
getting
huge,
it's
good
to
take
a
feedback,
but
if
we
want
to
get
it
merged,
I
would
say:
let's
we
should
start
doing
the
work
in
phases
to
get
this
much.
A
big
peer
might
introduce
a
lot
of
bugs
here
in
these
kind
of
implementation.
A
G
Yeah
so
raj
I've
got
a
question
for
you
regarding
some
of
this
behavior.
So
there's,
there's
kind
of
a
few
things
going
on.
You've
got
libraries
out
there
that
are
directly
using
activity
source
for
their
instrumentation,
and
so
you
technically
don't
need
an
instrumentation
library
to
interpret
that
data
and
get
it
flowing
through
through
open
telemetry.
A
E
From
my
perspective,
it
seems
like
we
would
want
to
always
capture
activity
sources
and,
like
the
the
original
motivation
for
this
pr
was
okay,
there's
a
specific
adapter
that
the
hotel
sdk
has
to
handle
and
decorate
further
asp.net
stuff.
E
That
seems
like
that
would
be
the
target
of
conditionally
enable
that,
but
keep
the
other
activity
sources
flowing
regardless.
I.
D
See
only
it's
the
only
one
problem,
at
least
I
I
don't
know.
I
know
that
it's
possible
to
enable
all.
But
if
there's
a
specific
library
which
has
problems
which
doesn't
have
the
declaration,
I
don't
know
if
there
is
an
ability
to
disable
like
only
one
library
using
carrying
currently
the
sdk.
I
think
it's
only
possible
to
add
new
sources,
but
it's
not
possible
to
remove
some
like
creating
a
block
list.
C
C
D
And
yeah,
but
one
thing
is
about
adding
the
sources
before,
but
we
could
also
like,
add
everything
and
make
an
exclusion
list,
and
it
could
be
also
before
so.
If
one
uses
like
the
default
behavior
to
instrument
everything,
but
once
you
just
not,
you
know
enable
but
just
disable
some
simple
source,
for
example.
D
Let's,
let's
assume
that
there's
some
some
library
abc
and
it
doesn't
use
the
activities
in
like
it
uses
like
it's
very
messy-
is
they're
using
it
for
debugging.
But
it's
not
really
handful
for
us
because,
for
example,
it
generates
a
million
of
spans
and
then
I
think
it
will
be
good
to
have
a
possibility
to
disable
it
yeah.
Currently,
the
disabling.
E
D
So
in
this
approach
the
user
can
have
like
two
behaviors
one
is
that
the
user
gets
our
verified
only
our
verified
instrumentations
like
in
erasmus
pr.
But
if
he's,
if,
if
he
wants
everything,
if
he
doesn't
care,
you
know
if,
if
some
library
was
tested
by
us,
he
can
just
put
an
asterisk,
and
if
it
works
fine,
then
it
will
work.
D
A
Agree
with
that,
but
if
someone
wants
to
do
that,
they
can
really
put
an
asterisk
in
one
of
our
environment
variables
in
the
custom
sources.
It
should
start
collecting
all
other
sources
in
that
way
in
this
one
doing
things
in
a
controlled
way
is
the
right
thing,
because,
even
if
like
in
that
way,
we
don't
know
where
what
breaks
or
what
we
collect,
how
to
stop
and
everything
you
know
in
doing
in
this
way
we'll
have
more
control
over
the
activity
sources
and
what
needs
to
be
done.
A
But
currently
I
feel
the
whatever
the
approach
proposed
is
fine,
but
it
requires
a
little
of
redesign
to
like.
A
G
I
mean
he
talked
about
the
activity
source
data
flowing
through
for
some
of
our
vetted
libraries
before
the
detectors
had
a
chance
to
to
run
necessarily
or
let's
say
it's
a
different
version.
So
our
detector
doesn't
pick
it
up
for
whatever
reason,
and
so
that
was
your
concern
about
data
flowing
through.
G
Trying
to
think
is
that
what
the
end
user
desires
or
or
not,
if
that
makes
sense,
because
they
won't
necessarily
know
those
nitty-gritty
details,
they'll
just
care
that
they're
seeing
data
flowing.
It
may
not
be
what
they
want,
but
they
may
not
find
it
out
until
they're
trying
to
see
the
data
in
their
in
whatever
tooling
they're
using,
and
it
may
be
that
oh
they're,
not
the
data's
not
showing
up,
because
it
doesn't
have
the
right
shape
or
it's
missing
some
sort
of
attribute
or
the
attributes
in
the
wrong
format
or
something
along
those
lines.
G
A
And
one
other
thing
to
add
on
top
of
that
is
like
the
expanse
that
are
emitted
by
the
general
like
asp.net,
core
or
http,
may
not
be
the
following:
the
open,
telemetry
semantic
conventions.
What
instrumentation
libraries
are
doing
is
it's
helping
us
like
map
to
that
and
provide
like
an
export
activity
for
us
in
that
way?
So
if
we
just
start
listening
to
it
without
an
instrumentation
library,
we
will
run
into
that
issue
where
we
are
not
following
any
semantics:
yeah
you
like
them.
G
G
So
so
anything
written
to
activity
source
these
activities
they
also
get
emitted
through
the
event
pipe
as
well,
and
so
other
diagnostic
toolings,
especially
out
of
process,
are
potentially
listening
to
those
to
the
things
on
the
event.
Pipe
and
we'll
see
discrepancies
between
them,
and
that
could
be
a
future
thing
that
that
leads
to
confusion
as
well,
especially
if
activity
source
is
being
touted
as
the
span
api
for
for
dotnet.
D
G
If
you
just
enable
the
activity
source
without
also
adding
the
the
instrumentation
library.
D
A
A
D
A
Intentionally
like
if
there
is
an
issue
just
like
there
is
a
random
issue
and
if
it
does
not
load,
we
will
be
doing
it
in
this
way
and
again,
like
even
with
or
without
that
event
handler
http
client
traces
are
getting
collected,
which
means
it
does
not
use
detector
at
all.
In
that
scenario,
I.
D
A
D
A
C
Yeah,
the
integration
test
doesn't
look
around.
It's
going
to
crash
the
more
sitkin
handler
because
the
tags
are
not
populated.
A
I
just
want
to,
as
you
are
naming
it
as
lazy.
I
just
want
to
check
if
there
is
a
really
an
approach
of
lazy
loading
where,
for
example,
there
is
a
startup
bootstrapper,
asp.net
core,
we
can
set
an
environment
variable
for
a
startup
bootstrapper,
where
we
won't
don't
load
things
during
the
startup
hookup.
It
happens
during
the
service
collection
time
or
really
in
the
asp.net
core.
So
in
that
way
we
will
have
a
complete
control
over.
A
A
After
yeah,
we
could
do
something
like
this,
for
example
like
if
you,
if
we
find
there
are
no
instrumentation
enabled
by
default
in
the
startup
code.
We
initializing
our
open
telemetry
builder
itself
is
like
a,
I
would
say,
tracer
provider,
resource
of
no
use.
We
can
defer
that
and
we
can
have
a
like
a
start,
just
a
approach
that
I'm
thinking.
On
the
top
of
my
mind.
Now
we
can
have
a
jump
startup
bootstrapper,
which
can
do
that
initialization
with
all
those
providers.
A
G
G
G
From
our
perspective,
I
guess
the
question
is:
what's
going
to
be
acceptable
in
in
the
default
case
and
so
raj,
I
think
you're
arguing
that
we're
we're
applying
some
level
of
vetting
to
to
the
setup
in
that.
If
we
know
that
certain
activity
sources
really
require
instrumentation
libraries
in
order
to
provide
a
good
experience,
we
don't
want
you
to
just
be
able
to
enable
those
activity
sources
without
adding
the
the
instrumentation
libraries,
and
so
is
that
a
stance
that
that
we
all
agree
with
or
at
least
agree
enough
to
move
forward
with.
D
D
A
C
D
Which
would
mean
that
if
someone
would
like
to
check
how
the
instrumentation
would
like,
like
chris
described,
that
only
using
the
sources
and
get
what
the
activity
sources
give
the
user,
you
will
need
to
give
to
the
like
excluded
instrumentations
everything.
D
A
A
D
D
Second
one
and
second
one
was
something
like
death
and
but
I
think
it
was
about
running
yeah
this
one
and
I
think
it
was
also
not
updated.
So
it's
even
useless.
So
I
assume
no
one
was
really
using
it.
E
Yeah,
those
are
probably
good
to
get
rid
of
the
devamp
is,
if
you
wanted
to
run
iis
like
you,
would
have
to
like
set
the
installer
or
set
the
like
the
core
profiler
stuff,
so
that's
kind
of
what
that
was
for,
but
for
most
other
things
you
can
just
run
integration
tests
and
they'll
just
start
up
just
fine.
E
A
G
A
G
I
I
took
a
look
at
that
one
and
then
yeah
robert
had
me
run
the
the
workflow
on
my
mac
locally
and
for
whatever
reason
I
saw
one
of
the
tests
fail,
but
I
haven't
had
the
attempt
to
dig
into
why
it
failed.
A
So,
moving
on
to
the
issues.
G
Yeah,
so
this
is
just
something
that
I've
run
into
with
other
applications.
I've
worked
on
that
have
had
methods
with
lots
of
optional
parameters
and
when
I've
had
to
refactor
code
in
some
of
those
methods
or
change,
change,
something
regarding
a
parameter
or
fix
a
bug
regarding
a
specific
parameter,
being
able
to
track
down
which
things
are
affected
by
that
change
was
actually
quite
difficult
because
of
the
mix
of
positional
method,
parameter,
passing
and
named
parameter.
G
Passing
like
the
a
lot
of
the
tooling
just,
doesn't
help
you
with
that
and
so
you're
stuck
with
doing
a
search
and
then
having
to
look
closely
and
counting
parameters
versus
whether,
if
you're
using
some
sort
of
config
object
or
settings
object,
it's
really
straightforward.
When
you
use
your
ide
to
find
usages
of
specific
settings
or
parameters,
it
just
makes
it
a
lot
easier.
E
G
Yeah
I
try
to
to
elaborate
with
an
example
in
in
there.
That's.
D
A
I'm
okay
with
it.
So
is
it
fine
because
we
are
planning
to
release
it's
a
refactoring
thing?
Shall
we
put
it
in
the
next.
G
Do
you
have
time
cruise
to
refactories
or
not
really,
maybe
this
week,
I'm
still
putting
together
my
schedule.
D
E
Yeah
the
the
propagating
trace
ids
seems
like
a
concern
for
the
sdk,
not
really
for
us.
I
would
kind
of
direct
them
there.
E
E
A
We
can
take
a
look
like
offline
on
this
one.
D
D
D
Any
collections
in
spanish,
I
think
oh
metrics
exported
it
was
about
test
of
the
metrics,
so
I
think
we
always
need
to
compare
the
latest
value
like
the
latest
snapshot.
So
I
was
just
thinking
about
refactoring,
this
otlp
mod
collector
and
everything
just
to
have
something
to
analyze.
The
latest
version
of
the
of
the
matrix
snapshot
yeah.
A
It
becomes
little
tricky
with
that
guy,
so
the
sdk
sends
two
kinds
of
metrics
every
metric
interval.
Whatever
we
said
it
sends
a
resource
metric
which
will
not
have
anything
about
whatever
the
instrumentation
that
we
have
it
and
it
will
be
combined
with
the
other
matrix.
That's
how
it
makes
it
very
complex.
So
maybe
we
having
something
to
remove
the
resource
metric
and
have
look
out
only
for
instrumentation
metric
will
make
it
very
easier.
A
D
Chris
was
also
telling
that
maybe
we
should
add
some
methods
to
validate
or
to
have
to
get
the
values
directly
like
from
the
mock.
So,
for
example,
we
could
have
something
which
gets
the
value
of
the
res
just
resource
metrics
from
from
the
mo
collector
or
just
you
know
this
instrumentation
matrix.
So
I
think
it's
a
broad
broad
thing.
That's
why
the
title
is
brought.
D
D
A
Yeah
this
we
did
it
in
a
different
way.
Instead
of
using
like
a
force
flash,
we
are
using
the
export
metric
interval
at
this
point.
G
I
think
it'll
be
good
eventually,
I
I
don't
know
that
it's
something
we
need
to
do
right
away
unless
there's
a
feature
request
that
that
comes
for
it,
especially
since
we
have
a
workaround
for
our
tests.
D
A
A
I
kept
this
diagnostic
source
spending
because
of
the
metrics
issue.
I
did
not
get
time
into
it
so,
as
like
most
of
the
work
is
complete
from
the
metric
perspective,
I'll
be
spending
some
time
on
this
and
also
I'll
try
to
build
the
prototype
on
logs.
When
I
take
a
look
into
this
one.
A
D
G
I
think
that
would
be
good.
I
think
we
could
have
a
follow-on
beta
where
we
add
some
logging
support.
A
Logging
is,
I
just
spent
initial
some
time
on
it.
It's
seems
to
be
a
little
difficult
at
this
point.
It's
not
as
easy
as
like,
adding
in
trace
or
matrix
it's
entirely
difficult,
and
at
this
point
it
looks
like
we
might
do
it.
We
can
do
it
only
through
the
profile
or
not
other
approach,
so
I
may
also
contact
the
dot
net
team
to
see
so
for
our
next
beta,
I
would
say,
like.
I
will
also
explore
the
avenues
for
the
logs
with
the
dotnet
team.
G
Yeah
and
I
think
the
otlp
exporter
for
logs
is
still
in
beta
as
as
well.
E
Yeah
the
instrumentation
focus
sounds
good,
then,
for
the
yeah,
that's
beta.
D
Raj,
I
don't
know,
I
think
you
can
try
just
reorder
the
things
on
the
backlog
on
the
left
side.
At
least
you
can
try
right
now.
A
D
A
D
Can
then
you
know
we
can
just
look
through
it
during
next
sig
meeting,
I
will
cr.
I
will
also
create
next
milestone
like
after
the
next
release,
so
we
can
move
the
things
that
we
think
that
there
should
be
close,
but
not
not
for
the
next
release.
What
do
you
think
like?
Similarly,
we
had
like
now
zero
to
one
then
I
can
also
create
zero.
Two
two
for
the
next
release.
A
No
I'll
we
can
do
that
offline.
We
can
use
the
time
for
any
other
discussion
pending
discussion.
G
Actually,
question
regarding
the
the
next
release
so
right
now
it's
labeled
as
zero
to
one
beta,
but
if
we're
talking
about
enabling
all
instrumentations
but
by
default
shoot,
should
that
be
a
0.3
or
do
we
think
0.2.1
is
okay.
E
F
G
Yeah,
so
we
can
just
simply
rename
that
milestone.
A
No
other
topic
added
for
discussion.
Sorry,
I'm
looking
at
things
correct.
A
G
G
At
the
very
least,
though,
if
people
can
still
manually
opt
into
to
logging,
if
they
want
some
of
the
things
that
they're
currently
missing
would
be
some
of
the
automatic,
contextual,
adding
of
information,
so
you're
not
going
to
get
trace.
80
spanish
on
your
your
logs
or
resources
added
to
your
logs,
unless
you
manually
do
something,
but
logs
can
still
be
sent
to
an
open,
telemetry
collector
through
other
means,
and
so
it's
not
like
us
not
having
the
built-in
support
for
logging
is
a
show
stopper
for
people.
D
D
A
Yeah
but
as
I
called
out,
it
is
little
tricky.
Maybe
when
we
get
time
we
should
start
exploring
how
to
get
that
done
so
because
normally
you
need
to
create
a
logger
and
have
that
logger
instance
like
to
send
the
data
to
the
exporter
and
if
we
need
to
get
a
hook
into
that
that
too,
before
the
application
starts.
It's
a
lot
trickier
in
that
space.