►
From YouTube: 2022-07-26 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
So
I'll
have
to
ask
someone
to
share
the
screen
like
blanche
or
ellen
utkash
is
not
going
to
join,
likely
he's
sick
and
roof.
I
am
from
my
phone.
I
still
I
might
try
to
share
it
later
if
no
one
has,
but
someone
can
share
the
screen.
That
will
be
great.
A
B
C
B
Yeah,
if
other
people
don't
have
things
to
talk
about,
should
we
just
jump
into
this
issue
that
I've
put
on
the
agenda.
A
Yeah,
let's
quickly
do
the
release
plan
make
sure,
like
everyone
knows
what's
that
next
early,
so
we
are
supposed
to
do
like
some
like
a
couple
of
days
back,
but
utkarshi
is
not
yet
working.
So
I'm
just
waiting
for
him
to
be
back
to
the
office,
because
I
want
to
basically
test.
A
He
has
all
the
credentials
to
do
the
release
because
he
was
recently
given
the
maintenance
status,
so
hopefully
by
tomorrow
we
can
do
the
first
beta
of
the
1.4,
I
think
yeah,
so
it
should
happen
like
sometime
in
the
next
two
days,
if
not
later.
A
The
second
update,
which
I
mean
not
update
like
something
which
I
wanted
was,
was
it
ever
discussed.
What
would
be
our
plan
to
bring
the
dot
net
seven
branch
back
to
the
main
branch?
Do
we
want
to
wait
for
any
more
time,
or
should
we
just
bring
it
back
to
the
main
branch,
with
the
assumption
that
there
won't
be
any
stable
release
until
now,
by
first
week,
when
the
dotnet
7
itself
is
stable,.
B
A
Yeah,
I
would
propose
to
do
that
because
the
prometheus
specification
is
still
not
done
and
even
if
it
gets
done
in
the
next
two
months,
we
can
just
ask
people.
Okay,
you
waited
like
so
many
years,
so
I
don't
wait
for
another
month
or
two
so
that
we
don't
need
to
maintain
two
different
branches:
the
instrumentation
library
changes
which
visualize
is
making
on
the
top
net.
Seven,
it's
going
to
be
a
big
thing
to
merge
it
back,
because
we
have
other
pr's
touching
the
exact
same
file.
A
So
this
is
different
from
how
we
handle
the
metrics,
because
matrix
was
a
completely
disjoint
set
of
files.
But
now
we
are
editing
the
same
file
in
two
branches,
which
is
going
to
be
a
very
difficult
thing
to
merge
back
so
no
objections.
Once
we
do
the
release,
we
will
bring
the
dot
net,
seven
branch
back
to
the
main,
and
we
will
announce
that
the
next
stable
release
will
only
be
on
number
first
field
or
second
week,
whenever
dotnet
seven
comes
out.
B
If
it
helps,
I
think
the
two
pr's
out
there
against
the
dot-net
seven
branch
that
vishwesh
was
working
on,
we
could
maybe
merge
those.
Now
I
think
they've
both
been
approved,
and
then
I
could
do
the
work
to
just
merge
maine
back
into
it
just
and
resolve
any
conflicts
that
may
be
there,
so
that
it's
right.
A
Yeah,
so
you
are
referring
to
doing
this
after
the
beta
one
release,
or
you
want
to
do
it
even
before
that.
B
A
Yeah
there
are
like
tiers
in
the
instrumentation,
both
in
main
branch
and
next
seven.
So
it's
going
to
be
very
interesting.
How
do
we
merge
it?
So
it's
better
if
you
do
it
like
in
the
next
two
days
itself,.
A
Yeah,
so
that's
the
only
thing
which
I
wanted
to
ask
about
the
overall
release
and
go
back
to
the
things
listed
in
the
agenda.
There
was
something
which
we
discussed
with.
I
think
I
don't
know
whether
it's
martin,
like
we
just
agreed
to
discuss
the
open,
telemetry
extension
start
hosting
as
well
today.
So
once
you
are
done
with
the
other
two
agent
items,
let's
discuss
the
stabilizing
release
of
open,
telemetry
extensions,
road
hosting
as
well.
D
If
you
want
to
introduce
yourself,
you
need
to
be
on
off
mute.
It's
a
thing,
I'm
working
on
it's
a
personal
growth
thing
so
yeah.
I
have
been
on
a
couple
of
these
before
I'm
devrel
for
honeycomb,
and
I
am
predominantly.net
by
predominantly
I
hate
all
of
the
languages,
so
you've
got
me
and
I'm
dedicated
to
this
one.
My
current
sort
of
focus
is
trying
to
increase
adoption
by
making
this
as
ga
as
we
possibly
can,
because
we're
getting
lots
of
pushback.
D
So
that's
the
focus
I
want
to
spend
a
lot
of
time
on
at
the
moment.
Hence
the
reason
looking
at
the
ins,
extensions
hosting,
which
is
the
current,
I
think
only
one
other
than
auto
instrumentation.
That
is
in
beta
that
most
of
our
customers
care
about
anyway,
but
yeah.
I
want
to
be
able
to
say
that
everything
is
stable.
D
So
that's
why
I've
been
pushing
that
but
yeah
I'm
here
to
help
and
I've
got
time
to
spend
on
these
things
thanks
for
sorting
out
the
tags,
whoever
it
was
that
did
that
for
the
extensions
hosting
stuff
I've
been
having
a
quick
look
through
those
and
I'll
have
more
time
to
spend
on
it
towards
the
end
of
the
week
yeah.
So.
A
Let's
go
through
the
agenda
and
discuss
the
extension
specifically
at
the
end.
Thank
you.
Yeah
salan,
like
let's
go
over
the
first
two
items
should
be
relatively
quick,
so
we'll
have
more
time
to
discuss
the
hosting
project.
B
Yeah,
you
bet
so
I'd,
be
it
looks
like
yeah.
We
got
some
more
eyes
on
this
pr.
I
this
pr
came
in
last
friday.
This
is
the
second
time
that
this
general
issue
has
come
up
so
basically
just
a
quick
overview.
The
asp.net
core
library,
when
there
are
exception
filters
installed.
B
There
are
some
events
that
get
fired
that
are
listener,
subscribes
to
or
or
gets
invoked
from
and
they're,
not
the
events
that
we're
looking
for
they're
specific
for
the
filter
before
and
after
they
have
a
totally
different
payload.
B
So
I
wanted
to
just
kind
of
have
a
brief
conversation
about,
given
that
our
contract
between
these
libraries
that
are
firing
these
events
and
the
the
diagnostic
source
listener
that
we
have
is
pretty
loose
like
the
contract.
Basically,
it
just
has
an
object,
payload
and
also.
B
I
have
a
handy
link
to
the
the
code.
Right
is,
has
a
very
generic,
it
looks
for
a
few
specific
keywords
ends
with
start
stop
exception.
B
Right
so
I
was
curious
about
people's
thoughts,
because
I
guess
there's
a
there's.
A
few
parts
to
this
contract
I
mean
part
of
it
is
the
the
event
name
which
is
loose
in
the
proposal
in
the
pr
that
I
said
is
like
maybe
that's
one
thing
to
tackle,
which
is
to
be
like
explicit
about
the
event
names
that
we
handle
somehow,
but
then,
of
course,
there's
the
payload
type
as
well,
which
is
passed
in
this
is
this
is
the
actual
like
it's
just
a
type
object.
B
So
you
know,
I
guess
that's
another
aspect
of
this
contract
that
we
could
pursue
like
making
that
more
explicit.
Somehow-
and
I
haven't
thought
very
deeply
about
that-
I
think
I
think
the
name
thing
would
probably
be
easier.
I
mean
really
it's
it's
about
more
something
like
just
on
custom
and
like
having
the
instrumentation
itself,
maybe
be
the
the
gating
factor
as
far
as
like
whether
it
handles
it
or
not.
A
Yeah
this
was
like
just
a
result
of
like
we
were
like
initially
having
only
like
two
instrumentation
libraries
like
espana,
core
and
http
client,
and
they
were
following
the
contract
at
that
time,
like
they
were
firing
an
event
with
ensign
start,
they
would
fire
an
event
which
ends
in
stop
and
they
would
fire
an
event
which
results
in
I
mean
ends
in
exception
and
the
mvc
anything
which
doesn't
fall
into
and
the
only
case
which
we
were
anticipating
at
that
time
was
mvc
firing,
couple
of
extra
events
about
the
routing
attributes
and
but
since
then
like,
it
was
used
by
pretty
much
all
the
instrumentation
libraries.
A
So
we
no
longer
have
a
good
inventory
of
what
are
the
events
we
are
even
subscribing
to
so
I
think
the
first
step
would
be
to
like
how
that
inventory,
like
what
are
the
things
which
we,
which
the
instrumentation
libraries
even
firing
like,
for
example,
sp
net
core
has
around
eight
or
ten
diagnostic
source.
Dot.
Right,
like
one
is
the
hosting
startup
like
when
you
start
the
request
pipeline
and
then
one
with
the
end,
and
then
one
exception
has
like
two
of
them.
A
Then
mvc
has
like
four
of
them
so,
instead
of
like
relying
on
this
like
ends
with,
we
should
be
looking
at
specifically
which
event
we
are
interested
in,
because
then
only
we
will
know
at
what
stage
in
the
request
processing
pipeline
was
this
fired
and
based
on
that
we
can
retrieve
the
payload,
because
in
some
cases
I
think
there
are
open
issues
as
well
like
if
you
try
to
access
the
authenticated
user
or
if
you
try
to
access
the
route,
we
won't
have
it
unless
and
until
the
this
itself
is
run.
A
So
there
are
like
few
issues
open
in
the
same
aspect,
so
basically
it
all
boils
down
to.
We
don't
really
have
a
like
contract,
like
which
even
we
are
supposed
to
listen
to.
Probably
we
are
listening
to
the
wrong
event.
A
There
could
be
like
better
events
which
we
should
be
leveraging,
so
I
think
the
easiest
way
to
get
like
a
resolution
is
just
document
start
with
the
inventory
of
all
the
events
which
are
fired
from,
let's
start
with
the
sp
net
core
and
http
client,
given
their
the
most
common
one
and
the
payload
associated
with
that.
The
majority
of
the
cases
we
don't
really
need
that
reflection
based
thing,
because
the
payload
is
a
public
type.
A
If
you
look
at
the
second
type
which
you
have
open
island
like
it
should
show
the
actual
payload
yeah,
it
is
a
before
exception,
filter
class,
and
that
is
a
public
class.
So
the
reason
I
believe
we
had
reflection
at
that
time
was
we
did
not
want
to
take
a
dependency
on
the
mvc
specific
package.
A
A
This
is
faster,
but
at
least
we'll
have
better
contracts,
because
we
are
like
specifically
looking
for
a
class
so
instead
of
like
trying
to
reflect
through
and
see
if
it
exists
or
not,
that
should
at
least
mitigate
like
some
of
these
issues
as
a
side
effect
like
while
we
are
at
it.
We
could
also
improve
the
enrich
and
filter
signature
also
because
right
now
they
are
also
just
object
object.
We
could
make
it
the
strong
type
like
http
context
or
http
request,
because
we
have
microsoft
asp.app
as
part
of
our
dependencies
yeah.
A
That's
my
overall
thinking,
because
I
I
yeah.
While
I
was
looking
at
something
completely
different,
I
encountered
the
same
issue
which
was
being
fixed
in
this
pr
as
well,
so
that
issue
is
basically
our
reliance
on
activity
dot
current.
A
A
So
I
have
asked
like
which
ways
to
like
write
a
unit
test
to
through
that
case,
where
people
can
be
creating
their
own
activity
in
their
middleware,
and
we
accidentally
access
that
activity.
We
think
that
it's
a
spin-off
core
one
and
we
try
to
modify
it
even
though
that
belongs
to
the
customer.
So
there
are
like
few
issues
arising
out
of
accessing
activity.
A
The
way
we
currently
so
again,
the
fix
for
that
is
also
to
document
the
the
events
which
they
are
fired
and
most
likely
the
payload
has
a
way
to
retrieve
the
activity,
because
I
haven't
done
the
full
research,
I
think,
which
will
be
here,
and
he
can
probably
show
like
how
to
retrieve
the
activity
without
relying
on
activity
dot
current,
because
the
framework
stores
the
activity
inside
some
http
feature
thing
so,
which
should
be
retrievable
from
the
http
contacts,
which
is
part
of
the
payload.
A
So
from
the
payload,
we
should
be
able
to
retrieve
the
exact
activity
which
the
framework
has
created
so
that
we
don't
interfere
with
the
customer
created
one
so
like
once.
We
have
the
inventory
of
all
events
along
with
the
payload
and
what
is
expected
action
to
be
done
in
the
instrumentation
libraries.
We
can
solve
a
class
of
problems
like
this.
One
is
one
particular
example,
but
there
are
four
or
five
issues
open
in
the
same
area
and
that
will
also
improve
the
ask,
which
I
think
plans.
A
Michael
blind
was
asking
for
a
long
time
like
we
should
modify
the
in
bridge
and
filter
to
be
like
strong
typed,
as
opposed
to
just
object,
object.
A
I
can
just
create
an
issue
describing
like
pretty
much
what
I
described
or
maybe
I
can
ask
bishwash
to
his
wishes
on
the
call,
maybe
if
he
has
done
some
research
yeah
he's
on
the
phone,
if
you
want
to
like
take
the
lead
like
create
an
issue
like
starting
with
the
document,
and
what
is
the
reason
why
we
are
having
this
at
least,
then
we
will
have
a
good
like
issue
tracking
what
we
are
going
to
do
in
the
next
few
days
on
the
instrumentation
libraries
and
we
solve
a
class
of
problems
as
opposed
to
solving
like
one
of
problems.
A
It
also
has
like
several
challenges
to
solve,
because
nothing
like
some
of
the
events
which
we
are
expecting
the
payload
they
are
only
public
like
a
particular
version
of
sp
network,
may
not
exist
in
3.1.
It
may
exist
in
like
6.0
in
a
different
shape.
So
so,
whenever
we
do
the
documenting
the
inventory
like,
we
should
also
list
which
framework
this
behavior
is
applicable
and
based
on
that,
we
need
to
do
the
conditional
comparison
as
well.
A
B
Yeah,
I
think
that
sounds
like
a
great
approach
and
also
yeah
specifically
focusing
on
asp.net
core,
because
it
probably
will
be
one
of
the
more
complicated
ones,
but
I
think
it
will
also
help
maybe
guide
future
insights
into
whether
taking
dependencies
on
the
third-party
libraries
that
we're
instrumenting
is
a
is
a
good
pattern
to
follow
for
other
libraries
as
well
or
not.
You
know
so.
A
Yeah,
so
all
those
guidance
came
from
the
dotnet
team
itself,
like
five
years
back
when
they
like
much
before
the
activity
came
like
the
diagnostic
listener
thing,
so
they
had
an
explicit
documentation
which
suggests
the
usage
of
reflection
source
to
prevent
taking
dependencies,
because
all
the
version
conflict
comes
with
that.
It's
mostly
true
except
like
for
the
ksp
network.
A
We
take
the
dependency
using
the
framework
dependency,
so
it's
like
now
that
we
anyway
have
that
dependency
like
we
should
just
leverage
it
to
make
a
better
experience,
but
it
might
not
be
true
for
everything
else
before
the
other
libraries
like
stack
exchange
and
for
release,
we
have
dependency
on
ready.
So
we
have
like,
like
the
opportunity
to
do
the
strong
type
thing
for
pretty
much
everything.
B
It
would
be
nice
to
have
some
like
yeah.
It
would
be
nice
to
have
some
technical
documentation
that
talks
about
the
events
or
other
things
that
all
of
our
instrumentation
depends
upon,
and
maybe
maybe
what
we
come
up
with
with
asp.net
core
can
be
the
model
for
documenting.
A
So
we
can
start
with
sp
net
core
and
see
where
it
lands
us,
because
the
spinner
code
is
the
one
where
most
issues
are
currently
open,
followed
by
http
client.
I
think
even
http
client
has
the
exception.
Filter
similar
issue.
It's
not
filter.
It
would
be
like
something
else
called
something
else
in
http
client
world,
but
we
still
have
the
similar
issue.
I
think.
A
I
mean,
if
you
search
for
all
the
issues
we
would
find
it
so
yeah
we'll
start
with
that.
Documenting
guess:
vishwash
is
here,
so
he
should
be
able
to
help
with
that
he's
already
doing
the
instrumentation
library
work
with
dot
net
runtime
folks.
So
that
would
give
us
the
list
to
begin
with,
and
we
can
see
like
step
by
step.
This
is
all
to
be
done
like
right
after
we
bring
the
seven
branch
back
into.
A
And
whatever
we
do,
it
should
be
applicable
for
metrics,
also
because
we
are
relying
on
the
diagnostic
source
for
metrics
also,
so
it
should
benefit
the
metric
also
because
if
you
are
like,
if
you
are
lying
on
the
exception,
we
need
to
rely
on
it
in
the
matrix.
Also
assuming
there
is
a
need
for
exception
type
or
something
as
a
metric
dimension.
B
Was
there
this
is
a
bit
of
a
tangent
but
which
you
did
some
experimentation
to
see.
If
you
could
do
metrics
without
the
dependency
on
diagnostic
source,
did
anything
ever
become
of
that.
C
No
yeah,
so
I
mean
I
I
did
something,
but
then
ultimately
we
figured
it
out
like
like
the
idea
was
to
do
metrics
without
relying
on
activity.
So
that
was
the
part
that
I
was
looking
at.
But
then,
even
though,
if
if
we
don't
want
to
rely
on
activity,
we
have
to
learn
the
diagnostic
source
and
that
will
will
end
up
creating
the
activity
anyways
so
for
like
asp.net,
core
and
http
for
backward
compatibility
purposes.
C
If
we
don't
have
activity,
source
listener,
4.7
onwards
and
we
do
have
diagnostic
source
listener,
the
activity
is
gonna
get
created.
So
like
that
part,
I
like,
I
was
starting
with
schedule,
so
we
could
just
keep
relying
on
the
activity
for
that,
because
we're
going
to
have
the
activity
object,
anyways,
but.
C
Part
like
on
the
other
instrumentation
libraries,
where
we,
where
we
create
the
activity,
I
think
in
sql
we
do
that.
So
that
is
something
we
could
look
at
and
I
I
had.
E
C
Draft
pr
with
which
I
closed,
but
I'm
gonna
look
into
that
again
at
some
point
of
time,
since
I'm
done
with
the
current
items.
A
So
our
general
recommendation
would
be
like
if
you
want
matrix,
you
use
a
matrix
api
directly,
so
we
can
enable
disable
matrix
independent
of
tracing.
That's
the
general
guideline,
however,
due
to
backward
compact
reasons,
as
which
was
just
described
for
http
client
and
sp
net
core,
even
if
we
subscribe
to
the
just
the
diagnostics
or
the
framework
is
anyway
going
to
create
an
activity.
A
So
that's
like
it's
there
for
backward
combat
reasons
in
the
framework.
So,
if
activities
anyway
being
created,
we
should
just
leverage
that
and
use
the
activity
duration,
but
for
other
things
we
could
use
like
some
other
like.
So
we
need
like
some
context
to
know
like
when
it
was
started,
so
we
can
calculate
the
duration,
so
might
be
like
using
local
or
something
else
so
for
non.
Like
known,
I
mean
for
these
libraries
other
than
http
client
and
asp.net
core.
A
A
A
Okay,
any
further
questions,
if
not
we'll
create
an
issue,
and
we
can
discuss
like
specifics
in
the
description
itself
or
in
subsequent
peers,
which
we
will
do
only
after.
We
bring
the
dot
net.
Certain
branch
back
to
the
main.
B
Sounds
good
so
moving
on.
C
Hey
yeah,
I
just
wanted
to
bring
up
this
binary
search
pr
for
histograms
to
find
the
right
bucket
yeah,
just
if,
like
anybody
wanted
to
review
it
further
or
to
get
this
into
a
release,.
A
C
Okay
yeah,
so
I
determined
that
around
like
the
50
point
mark,
that's
when
at
least
on
my
system,
it
would
be
faster
to
use
binary
search
than
to
use
just
the
existing
linear
search.
So
that's
what
I
coded
in
as
like
the
switches
over
to
binary.
If
there's
50
or
more
boundaries.
A
Yeah,
so
one
thing
is
like
in
long
time
like
really:
we
want
to
make
this
problem
go
away
by
asking
people
to
use
exponential
histogram,
but
it's
really
long
time
because,
like
riley
is
still
like
doing
some
prototype,
the
spec
is
still
being
debated,
so
it
will
be
a
long
time
before
we
can
leverage
that
and
until
then
this
I
think
it's
a
good
addition.
Is
there
any
block
from
on
this
pr
or
you're
just
asking
for
people
to
take
your
first
look,
since
you
did
some
recent
changes.
C
There
is
some
like
changes,
but
it's
mostly,
I
think
it's
good
riley
and
utkarsh
looked
at
it
for
me,
and
blanche
also
helped
a
lot
with
the
the
actual
like
improvements
of
the
the
binary
search
like
the
implementation
there.
So,
okay.
A
A
C
Try
to
push
this
and
get
it
merged,
so
people
who
do
actually
use
like
a
lot
of
buckets
can
then
gain
performance
back.
A
So,
what's
like
benchmarking,
are
you
using
the
benchmark
or
are
you
using
the
structures
to
test
this
part.
A
C
A
A
It's
independent
of
this
one,
okay,
yeah,
we'll
review
it
and
we
can
see
when
we
can
do
it.
Don't
don't
expect
to
like
make
it
part
of
the
release
which
we
plan
to
do
tomorrow,
because
I
I
likely
have
less
time
to
merge
this
in
today,
yeah
yeah,
so
yeah.
It
should
be
like
right
after
the
anyway,
it's
a
beta,
so
we
have
plenty
of
time
to
stabilize
it
if
things
are
done
working
as
expected,
or
if
people
expect
they
want
to
control
the
number
of
buckets
after
which
we
switch
the
algorithm.
C
C
A
C
A
Yeah
yeah
yeah,
so
this
level
did
not
exist
because,
like
we
had
this
project,
probably
from
like
very
early
days,
but
we
never
had
the
time
to
prioritize
like
fixing
it
with
all
the
issues
there
are
like
opening.
These
are
just
the
open
issues
and
there
are
like
three
or
four
pr's
some
by
myself,
some
maybe
by
allen
and
plants
all
like
sitting
in
the
stale
marker
in
the
still
and
got
closed
because
we
were
working
on
other
things.
So
so
this
was
just
a
like
clean
up.
A
We
now
know
which
issues
to
look
at
and
what
are
the
issues
which
we
need
to
solve
before
we
call
it
stable.
There
is
one
uber
issue
which
is
about
like,
should
we
even
host
it
in
the
core
report?
Should
we
move
it
to
the
contrib
repo
and
also
the
name
like
there
were
like
some
comments
about?
A
Should
it
be
named
as
extension.hosting
or
there
were
like
some
alternate
proposals,
so
those
are
the
like
overall
things,
so
maybe
like
martin,
since
you
have
some
time,
let's
look
at
it
and
see
like
what
are
the
things
which
we
really
need
before
we
call
it
stable
there.
The
open
pr's,
which
you
will
find
when
you
click
on
the
issues
which
got
closed
in
still
with
scale
marking
that
should
explain
some
of
the
challenges
or
the
debates
we
had.
I
think
it
was
not
just
like
debate.
A
D
What
are
the
concrete
steps
that
you're
looking
for
on
these
to
to
get
them
to
a
point?
Do
you
just
want
answers
and
decisions
to
be
made,
because
obviously
I
can
provide
opinions,
but
it
sounds
like
there's
already
opinions
in
these
in
these
particular
things.
So
you
know
the
configuration
one
that
one's
fairly
simple
to
to
fix,
but
the
should
the
hosting
package
live
inside
of
this
repo.
I
think
it
should
should
it
have
dependency
injection.
Yes,
it
should
probably
have
dependency
injection
rather
than
hosting.
D
You
know.
I
have
opinions
on
those
things
and
I
can
make
the
changes.
But
what
do
you
think
we
need
to
do
to
get
so
that
we
don't
keep
going
around
in
circles.
A
So
the
the
two
issues
which
you
last
described,
the
name
of
the
package
and
the
location,
I
think
we'll
there
is
an
already
an
issue,
so
we
can
like
I'll.
Let
other
maintainers,
also
chime
in
to
see
whether
this
is
something
which
we
want
to
host
in
the
core
repo
or
not.
So
let's
have
the
discussion
in
that
specific
issue
itself
about
the
naming,
also
like
whether
this
name
is
good
or
we
need
a
different
name.
A
A
We
even
have
a
test
case
added
to
prove
that
it's
a
bug,
maybe
some
people
think
that
it's
not
a
bug,
it's
it's
like
by
design,
and
then
there
are
few
issues
which
are
more
about
like
usability
like
what
is
the
expectation
from
user
like
you
call
like
services,
dot,
add
open,
telemetry
tracing,
and
how
do
you
configure
like
sampler?
Do
you
just
add
the
sampler
to
the
da
and
we'll
just
pick
it
up
magically,
or
do
we
always
have
to
do
like
something
else?
A
So
these
were
the
questions
which
we
were
discussing,
but
we
didn't
have
the
actual
answer
or
we
didn't
have
the
time
to
actually
respond
to
each
other's
question
at
that
time.
So,
specifically,
what
we
expect
is
click
on
the
issue
and
you
can
see
the
pr's.
If
you
have
time
you
can
submit
a
fresh
pr
or
resurrect
that
same
pr
resolving
the
open
comments
that
should
be
pretty
much
like.
D
Say
I
can,
I
can
go
through
and
add
comments,
but
what
I'm
concerned
about
is
how
do
we
move
it
forward
because
who's
going
to
make
those
decisions?
When
are
we
going
to
make
those
decisions?
You
had
the
problem
before
where
you're
obviously
very
busy
get
it,
but
I
don't
see
that
changing
from
what
you
were
talking
about.
You're
you've
got
all
the
priorities
on.
So
how
do.
A
I
get
it
yeah,
so
this
is.
This
is
something
which
we
just
pundit
from
the
original
release,
because
we
wanted
to
focus
on
this
table.
It
was
again
funded
for
matrix
because
matrix
was
separated,
and
this
is
the
right
time
to
look
at
it.
So
I
I
can
commit
my
time
to
like
make
this
stable.
So
that's
why
we
said
okay.
This
is
the
right
time
to
bring
it
up,
because
we
don't
have
like
any
other
like
p0
things
to
tackle.
A
E
I
have
kind
of
a
curveball
to
throw
here.
Originally,
I
think
when
we
added
the
hosting
package,
we
didn't
have
any
of
these
artifacts
sort
of
in
the
sdk
dependency
graph.
Let's
say
later
on,
we
added
logging
into
the
sdk,
the
logging
packages
pull
in
dependency
injection
and
dependency
injection
abstractions,
so
we
have
actually
in
the
sdk
I-service
collection,
most
of
everything
hosting
needs,
with
the
exception
of
I
hosted
service,
so
I'm
actually
working
on
right.
E
Now
I
did
those
siri
log
and
event
source
prs,
they're,
sort
of
not
fitting
in
closely
because
logging
provider
doesn't
have
any
dependency
injection.
Currently,
so
I'm
looking
at
the
open,
telemetry
logger
provider
and
how
I
can
get
dependency
injection
as
part
of
it
and
what
I'm
finding
is.
I
can
pretty
much
do
it
all
in
the
sdk.
E
I
don't
need
a
hosting
package
for
that,
so
I
think
we
might
actually
be
able
to
fold
some
of
what
is
in
hosting
back
into
the
sdk
if
we
want
to
and
then
in
hosting
just
have
the
extensions
and
the
hosted
service
so
like
right
now,
there's
the
the
interface
deferred
the
deferred
providers
in
that
hosting
package.
They
have
their
specific,
like
hosting
version
of
the
builders.
C
E
E
E
E
A
A
I
mean
like
really
thought
about
this,
so
if
you
have
already
like
gone
through
that,
like
thinking
process.
E
But
as
I
was
doing,
logging
I
was
thinking
hey,
I
could
really
do
the
same
thing
in
the
tracer
and
it
would
smooth
out
like
there's
some
weirdness.
If
you
look
at
the
extensions,
what
they
do
is
say
like
okay,
if
the
provider
is,
I
deferred
provider,
then
do
the
hookup,
otherwise
it
basically
just
no
ops,
so
users
that
are
doing
it
incorrectly
they'll
just
fail
silently.
E
What
I'm
able
to
do
in
the
login
side
is
so
I've
added
a
couple
new
methods
where
you
can
register
sort
of
late
bound
actions
once
the
service
provider
is
available,
and
then
I
can
detect
when
I'm
in
that
build
phase.
If
it's
being
built
up
outside
of
dependency
injection,
then
I
can
throw
a
nice
exception.
Saying:
hey
you
registered
configuration
actions
that
I
can't
execute
like
you
made
a
mistake,
go
fix
it.
We
can't
really
do
that
today.
B
I
don't
really
understand
the
technical
challenges,
but
I've
heard
from
the
instrumentation
sig
that
the
fact
that
there's
a
dependency
on
the
logging
stuff
is
actually
making
it
things
more
challenging
for
them
in
terms
of
like
you
know,
if
somebody,
if
an
application
of
an
end
user
has
referenced
a
different
version
of
the
logging
dependency
than
what
the
sdk
does,
then
they
can
run
into
like
a
tricky
loading
scenario
like
which,
which
assembly
to
load
again.
E
I
wouldn't
expect
it
to
because
we're
only
going
to
rely
on
some
pretty
simple
interfaces
like
I
service
collection,
which
has
been
part
of
dependency
injection
abstraction.
Since,
like
its
first
version,
we
won't
be
adding
any
other
package
dependencies
that
I'm
aware
of,
but
I
don't
think
could
it
would
be
a
problem.
But
we
have
to
kind
of
try
it
and
see
he's
either,
obviously
to
move
logging
out
of
sdk.
But
I
think
that
will
be
massively
breaking.
E
A
So
island,
like
you,
can
click
click
at
the
nougat.
Then
that's
the
easy
way
to
see
it
right.
C
B
B
A
E
E
D
I
mean
the
the
big
worry
and
I've
been
coming
across
this
at
the
moment
with
looking
at
webassembly,
and
things
like
that
is,
there
are
some
things
like
using
a
batch
processor
by
default
for
otrp
exporter
just
doesn't
work
because
of
threading,
so
what
of
these
dependencies
are
bringing
stuff
in
that
will
stop,
say,
unity
or
web
assembly
or
stuff
like
that
from
just
working
out
the
box.
D
It's
more,
I
mean
there
was
an
issue
merged
in
recently
around
the
use
of
process,
so
there
was
a
static
that
was
using
process,
and
that
meant
that
the
library
could
not
be
used
at
all,
never
mind
if
you
moved
it
up
yourself,
because
as
soon
as
you
started
a
resource
builder,
it
was
using
system.diagnostics.process
that
was
merging
recently
and
that's
my
concern
is,
if
we're
bringing
those
things
in
as
a
dependency,
we
can't
take
the
strategy
that
you
were
talking
about,
where
we
just
knew
it
up,
because
well,
there's
a
static
that
pulls
in
data.
B
D
Yeah,
that
was
that
was
blazer.
Blazer
doesn't
have
access
to
diagnostics.process
and
throws
an
exception
as
soon
as
you
try
and
use
it,
and
because
we
had
a
static
fallback
inside
of
the
resource
builder,
the
as
soon
as
you
nude
up
a
resource
builder,
it
tried
to
access
process,
so
it
had
a
fallback
and
that
was
stored
in
a
static
somebody
merged
in
a
try
catch
around
it,
which,
I
don't
think
is
the
right
approach,
but
it
fixes
it
for
now.
D
So
the
worry
is
that
you
know
all
these
dependencies,
which
ones
of
those
have
something
similar
that
stop
us
from
being
able
to
use
it
on
obscure
or
niche.
Do
we
say
platforms.
E
Let
me
I'm
close
to
having
a
pr
for
the
logging
side,
so
let
me
open
that,
so
you
guys
can
kind
of
see
what
I'm
talking
about.
E
Basically,
it
is
just
if
you
look
in
the
hosting
package
at
the
hosting
specific
builders.
They
basically
just
give
you
a
list
of
sort
of
action,
callbacks
that
we
fire
off.
When
once
we
have
the
service
provider,
then
we
have
a
couple
methods
for
like
making
it
easy
to
say,
like
I
want
to
add
a
processor
that
I'm
going
to
pull
in
through
dependency
injection.
E
E
D
I
think
we
are
protected
by
the
fact
that
the
even
like
http,
client
factory
and
things
like
that
they're
all
really
really
tied
to
you,
building
a
service
provider.
If
you
don't
have
one
so
even
in
a
console
app.
Everything
is
now
depending
on
service
provider
anyway,
so
kind
of
protected.
By
that,
I
suppose
a
little
bit.
E
We
basically
register
a
hosted
service
so
that,
when
the
hosting
whatever
it
is
web
host
or
generic
host,
so
line
129
when
it
finally
is
ready
to
go,
and
it
starts
up
that
telemetry
hosted
service
basically
is
run.
Then
we
pull
our
providers
out
of
dependency
injection
and
basically,
everything
starts
up.
E
C
D
It's
it's
one
of
the
things
that
worries
me
about
the
approach
of
using
the
batching
processor
that
it's
firing
up
its
own
threads
internally,
which
realistically
I
would
have
thought
that
would
have
been
part
of
the
hosting
service
so
that
that
would
fire
off
a
background
service
as
part
of
asp.net
or
provide
you
with
some
other
way
of
controlling
it.
But
that's
a
much
much
wider
concern.
At
the
moment,
the
just
using
the
batching
processor
uses
its
own
thread
management.
In
the
background.
A
Yeah
batching
and
the
metric
also
has
its
own
periodic
exporter
kind
of
thing.
D
Yeah-
and
it's
the
if
you
even
if
you
knew
it
up
yourself,
it
is
going
to
have
threads
in
the
background,
which
is
it
wasn't
the
first
thing
that
came
to
mind
when
I
was
doing
it.
I
thought
the
hosting
provider
was
doing
the
flush
in
the
background,
which
is
not
it's
just
storing
the
object,
so
they
don't
get
disposed.
E
E
Otherwise
we
just
do
nothing
so
how
it
could
change
is
these
little
helpers
could
be
off
the
base
class,
so
you
can
call
them
when
you're
bootstrapping
and
then,
when
we
call
build
we'll,
we
will
know
at
that
time
whether
or
not
we're
building
through
dependency,
injection
or
manual.
If
it's
manually,
we
can
look
at
the
list
and
say:
oh,
you
registered
all
this
deferred
stuff,
but
you
don't
have
a
service
provider
now
we're
going
to
throw
and
give
you.
E
You
know
at
startup
time,
while
you're
developing
a
nice
error,
letting
you
know
this
won't
work
like
you
think
it's
going
to
work.
We
can't
really
do
that
today
because
it's
split
in
these
two
libraries,
so
that
would
be
the
big
advantage.
If
we
fold
some
of
this
into
sdk,
we
can
basically
eliminate
all
this
duct
typing
that
we're
doing.
D
I've
been
struggling
to
follow
what
your
ideas
are,
so
I
think,
starting
with
a
pr
and
maybe
collaborating
on
a
pr
might
be
a
a
better
way
of
doing
it.
Okay
sounds.
E
A
D
So
we're
saying
that
those
there's
those
five
issues
for
extensions
hosting
those
are
the
five
that
we
need
answers
on
before
we
can
go
ga
with
a
1.0
release.
A
Yeah
slightly
different,
because
if
you
are
moving
things
directly
into
the
sdk,
then
some
of
these
issues
may
not
be
an
issue
anymore.
So
yeah,
that's
why
I
said
we
need
answers.
D
A
Yeah,
I
don't
I
mean
I'm
not
aware
of
anything
else,
which
I
mean
assuming
like
blanche
did
not
have
this
way
of
bundling
things
into
sdk,
like
the
only
thing
which
we
were
aware
of
which
blocked
the
release
of
extension.hosting
was
captured
here
and
the
prs
which
are
like
attempting
to
or
claiming
to
solve
some
of
these
issues.
So
there
were
no
other
things
which
were
blocking
it.
There
is
no
spec
issue,
there
is
no
other
like
architecture
issue
or
anything
which
is
locking
this.
D
So
I
work
with
so
is
it
blanche
or
mike?
What
do
you
prefer
sorry,
either
one's
fine.
D
I'll
work
with
you
on
that
pr,
and
once
we've
got
that
in
a
nice
state,
then
we
do
these
five.
They
may
already
be
answered
and
moved
and
then
that's
our
path
forward,
and
I
will
what
I'll
do
I'll
put
a
comment
on
that
third
issue
down
about
the
release?
That's
what
we're
trying
to
do
that
makes
sense.
A
Yeah,
so
if
there
are
like
still
follow-ups
we
could
discuss
in
the
slack
channel,
we
don't
need
to
really
wait
for
the
next
meeting.
We
can
always
discuss
in
the
slack
channel,
okay
yeah.
Let's
move
to
that.
F
This
next
an
issue
from
the
auto
instrumentation,
so
I'll
just
give
a
background
about
the
issue.
So
when
we
use
the
opentelemetry.net
auto
instrumentation,
what
it
does
is
it
takes
the
sdk
like
libraries
and
integrates
that
with
the
customer
application
or
injects
it
during
the
startup.
That's
how
we
collect
the
telemetry.
F
So
there
are
no
issues
with
this
approach.
If
customer
has
an
app
which
does
not
have
an
open,
telemetry
sdk
already
within
it,
everything
will
work
seamlessly
if
customer
has
either
open,
telemetry,
apa
or
open
telemetry
sdk
and
when
an
auto
instrumentation
also
brings
its
own
sdk.
So
both
of
them
will
crea
will
go
ahead
and
create
their
own,
like
tracer
provider
or
meter
provider,
and
these
are
going
to
collect
the
telemetries
both
of
these
and
going
to
create
a
duplicate
telemetry
and
send
it
to
their
exporters.
F
So
we
wanted
an
approach
like
like
auto
instrumentation
injects
hd
sdk
at
a
very
very
earlier
stage,
even
before
the
the
application
starts
up.
Even
before
that
we
create
the
tracer
provider.
So
we
want
a
way
to
avoid
any
further
tracer
provider
or
meter
provided
after
that
moment.
So
currently
we
don't
have
a
way
for
it,
so
just
want
to
check
like
if
I
can,
if
we
are
in
agreement,
I
want
to
just
go
ahead
and
see
like
send
a
pr
over
here.
F
The
pr
is
going
to
be
very
simple:
I'm
I'm
planning
in
to
either
have
a
like
a
internal
like
a
flag
in
the
tracer
provider
builder.
Once
that
is
set,
we
can
stop
building
the
tracer
provider
itself
and
send
the
default
provider
back
instead
of
sending
the
one
with
the
all
the
instrumentation
and
exporter.
A
And
the
idea
is
that
the
auto
instrumentation,
when
it
does
the
like
loading
it
just
loads
its
own
provider
and
disables
everything
else.
F
Correct
it
disables
this
through
the
reflection.
There's
no
need
to
be
public.
We
can
have
it
as
a
private
static
in
the
like
a
sdk,
so
only
it
can
be
utilized
by
auto
instrumentation.
So
it's
not
a
public
api.
F
A
F
F
And
even
if
he
has
a
like
a
custom
like
instrumentation
or
processor
written,
even
we
have
a
way
that
can
be
plugged
in
in
the
auto
instrumentation.
A
Okay,
so
he
has
to
like
follow
the
auto
instrumentation
rules,
correct
okay,
the
existing
things
would
not
be
like
respected
at
all
so
by
default.
If
I
have
a
activity
source
myself
creating
things
and
I
have
hooked
it
up
to
my
provider,
then
I
enable
auto
instrumentation.
It's
my
responsibility
to
explicitly
previous
that
activity,
source
through
environment
variable
or
whatever
auto
instrumentation
recommends
correct.
F
A
Which
means
like
the
sdk
would
leave
like
as
it
is
like.
You
won't
try
to
disable
the
one
from
correct.
Yes,
I
mean
if
the
user
says:
okay,
I'm
okay
with
duplicates
whatever
correct
okay,
so
I
think
your
feature
request
is
not
to
prevent
that
telemetry
collection,
it's
just
to
prevent
the
builder
from
being
built.
A
F
A
Any
thoughts
on
this
like
branch
or
like
ellen,
I
don't
see
like
any
issues,
especially
since
auto
instrumentation,
can't
rely
on
the
reflective
way
to
access
whatever
flag.
We
expose.
A
It
might
be
like
slightly
related
to
what
we
were
discussing
just
before,
because
we
might
have
some
tweaks
in
the
way
we
are
building.
We
might
now
try
to
grab
things
from
bi
and
all
so
I
mean
it's
not
really
an
issue
I
was
just
saying
there
might
be
like
more
work
happening
in
the
same
area.
Okay,.
F
A
Yeah,
I
don't
see
any
issues
of
top
of
my
head,
so
I
think
yeah
you
can
create
a
maybe
electronic
pr
just
to
show
how
you
would
leverage
it
and
get
instrumentation
and
then
we
can
take
it
from
any.
Since
it's
not
public,
it's
like
it
has
like
less
entry
bar.
So
that's
one
good
thing.
A
All
right
in
any
other,
open
topics
which
we
want
to
discuss.
Let
me
see
there
is
some
chat,
one
second,
okay,
so
martin
says
bye
and
mothra
is
asking:
where
should
we
inventory
events?
Should
we
start
they
mark
down
in
the
diagnostics?
So
not
really
so.
The
diagnostic
sourcer
is
just
like
a
helper
thing,
which
is
used
by
the
individual
instrumentation
libraries
like
asp.net
core
and
also,
I
think,
the
responsibility
of
documenting
which
events
I
care
about
is
on
the
instrumentation
library.
So
if
it's
sp
core,
then
it
should
list.
A
These
are
the
events
which
the
library
which
I'm
targeting
is
firing,
and
these
are
the
payloads
and
of
that
I
am
only
interested
in
like
x
and
y,
and
I
don't
care
about
the
other,
so
don't
even
bother
firing
that
so
it's
more
like
a
internal
implementation,
detail
of
the
instrumentation
library
so
would
best
be
served
as
a
small
section
in
the
readme
or
we
can
start
with
that.
Just
github
disk
issue
and
decide
whether
we
even
want
to
like
document
it
is
part
of
the
readme.
C
A
question
before
you
would
assign
this
to
create
an
issue
so
I'll
discuss
it
in
the
issue
when
the
issue
is
created.
A
It's
a
very
broad
issue:
it's
not
just
documenting,
like
that's
just
the
first
step,
because
I
mean,
if
you
look
at
all
the
issues
which
are
open
about
espionage,
you
would
see
there
are
a
bunch
of
problems.
So
the
goal
is
to
have
a
like
non
list
of
events
and
then
solve
it
for
all.
A
Instead
of
fixing
issues
one
by
one,
because
most
likely
with
that
we'll
be
able
to
solve
a
class
of
problems
completely,
and
that
would
make
the
instrumentation
library
ready
for
stable
whenever
the
semantic
inventions
become
stable,
because
as
of
today,
even
if
the,
even
if
semantic
convention
say
we
are
stable,
we
won't
be
able
to
feel
comfortable.
Releasing
this
as
stable.
So
that's
why
I
want
to
like
start
with
the
list
first
and
then
take
step
by
step
in
that.
C
I
was
interested
in
helping
to
contribute
to
that
so
I'll
make
sure
I
discuss
with
vishwas
when
he.
A
Gets
started
yeah,
so
all
those
things
like
probably
have
a
long
history
in
application
sites
as
well,
because
all
these
events
were
originally
leveraged
by
application
insights
and
then
the
original
maintenance
of
this
report
like
sergey
and
mila.
They
just
borrowed
it
into
open
telemetry
as
well,
so
yeah.
E
A
From
yeah
so
for
http,
client
and
spinner
code,
I
think
they
were
like
extremely
careful
with
not
breaking
anything
so
far,
but
yeah
we
have
seen
breakage
in
like
sql,
client
and
other
places,
yeah,
okay,
think
so
we'll
ask
issues
to
create
an
issue
and
like
I
think
it
would
probably
be
a
fairly
big
effort
with
multiple
people
involved.
So
hopefully
you
can
also
like
help
with
that
part
and
yeah.