►
From YouTube: 2022-08-09 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
I
think
we
can
start.
We
have
a
couple
of
items
in
the
agenda,
so
please
get
started.
Can
you
talk
about
the
way.
C
So
semi
mini
already
I'm
working
to
increase
code
coverage
just
throughout
the
repo
and
spent
some
time
yesterday
investigating
code
coverage
specifically,
and
if
this
is
stop
me
if
this
is
like
common
knowledge
already,
but
I'm
kind
of
new
to
the
repo.
C
So
this
was
news
to
me
kind
of
surprising
so
code
coverage
and
if
anybody's
created
PR
has
probably
seen
that
you'll
get
just
kind
of
random
percentages
where,
like
you've,
increased
or
decreased
coverage
on
files
that
were
like,
we
didn't
touch
yeah
and
so
I
found
one
of
the
the
reasons
for
that.
So.
C
Yeah,
so
if
you
go
to
the
back
to
the
issue
that
I
opened,
I've
got
a
an
example
PR,
which
I
think
like
illustrates
it.
Like
perfectly
so:
yeah
yeah,
you
want
to
open
the
PR,
but
you
can
just
open
the
screenshot,
because
I've
been
oh
screenshot,
very
screenshot,
all
the
little
black
arrows
okay.
So
you
can
do
the
above
that
there's
another
screenshot
first
yeah.
C
So
this
PR,
the
guy,
only
changed
three
files
related
to
zero
log,
but
code
coverage
is
reporting,
19
impacted
files,
which
is
just
well
wrong
and
I
figured
out
why
that
is
so.
If
you
scroll
down
to
the
next
screenshot.
So
this
guy
created
his
PR
off
of
that
merge
net
7.0
that
a70
commit
ID
and
we
see
in
the
commit
history
the
black
that
I've
got
highlighted
the
A7.
C
But
then
two
above
that
was
my
PR,
where
I
increased
code
coverage
of
about
eight
or
nine
classes
and
I
got
those
up
to
100
percent.
C
But
then
the
serolog
pr
is
actually
reporting
that
it
got
those
files
up
to
the
100
percent.
And
so
the
reason
is
code
coverage.
The
tool
is
not
comparing
a
PR
with
the
current
head
of
Maine:
it's
comparing
the
pr
with
the
the
point
of
main
from
where
it
was
forked
from
so
the
serial
PR
forked
it.
You
know
like
four
commits
back
and
so
it's
but
then,
as
you
like
work
on
the
pr,
you
continue
to
merge
in
main,
merge
in
Maine.
C
So
now
it's
treating
that
that
PR
and
then
comparing
it
to
a
much
older
version
of
main.
So
that's
why
all
these
numbers
are
so
off
that
I
think
will
eventually
go
away
as
we
just
increase
coverage
overall.
What's
more
alarming,
though,
is
yeah
this
number
two,
so
in
addition
to
the
files
again
because
I
only
fixed
like
eight
or
nine
files,
but
the
pr
reported
19
files
affected
among
those
files
affected
were
event
switch
classes.
And
so,
if
you
look
at
these
screenshots,
it's
saying
that.
C
Well,
this
serial
log
PR
removed
coverage
for
things
in
Event
Source.
If
you
look
at
that,
the
the
very
first
screenshot,
like
you,
got
number
two
and
number
three
expanded,
because
look
at
that
first,
one
right.
Yes,
sorry,
it
says
actually
increased
coverage
there
again.
His
PR
doesn't
touch
any
of
these
things,
so
I
discussed
this
with
Riley
and
what
we
think
might
be
happening.
C
This
is
just
a
theory.
Is
that
integration?
We
have
all
these
other
integration
tests
in
this
repo
and
we
think
the
integration
tests
might
be
encountering
some
concurrency
issues,
and
so
one
do
you
imagine
like
one
execution
is
running
something
an
exception
gets
thrown,
which
is
not
like
the
object
of
what's
being
tested,
but
because
an
exception
gets
thrown.
It
would
then
log,
you
know
like
the
Event
Source
methods,
so
our
our
theory
is
that
the
might
be
some
variability
in
some
of
our
unit
tests.
C
These
are
the
functional
integration
that
is
just
causing
different,
like
other
classes,
to
be
executed,
kind
of
like
in
different
orders.
So
that's
our
going
Theory
I'm
gonna
be
paying
attention
to
this
specifically
over
the
next
couple
of
weeks
and
try
to
look
for.
Is
it
always
the
same
classes
that
are
being
reported
as
having
this
variability?
C
And
then,
if
you
scroll
down
to
the
next
steps
things
that
we
can
do
to
to
fix
this,
as
we
continue
to
increase
code
coverage,
I
would
expect
this
noise
to
just
fade
away
right
like
if
we
have
dedicated
unit
tests,
that's
hitting
like
specific
methods.
Those
methods
shouldn't
show
up
in
this
variability
that,
like
oh,
hey,
this
run
it's
covered.
This
run,
it's
not
covered
something
we
discussed
as
well.
Maybe
we
shouldn't
be,
including
the
integration
tests
as
part
of
the
code
coverage
results.
C
C
And
yeah,
that's
really
it
so
I
wanted
to
share
my
learnings
just
like
hey.
This
is
why
we
see
so
much
variability
in
the
code
coverage
in
everybody's
PR's.
This
is
where
it's
coming
from,
and
then
this
is
the
things
that
I
actually
pay
attention
to.
B
Is
this
something
which
do
you
know
the
answer
to
the
code
coverage
using
the
commit
from
which
it
was
branched
off
and
not
the
current
head?
I.
C
Did
I
did
some
digging
through
their
docks.
I
cannot
find
any
customization
for
this
specifically.
C
If
someone
else
wants
to
take
a
look,
if
someone
is
more
familiarity
with
code
coverage
than
I
do,
maybe
you
can
find
it
I,
just
I
couldn't
find
it.
As
of
Friday.
I
was
looking
into
this
yeah.
Could
you
consider.
B
Like
thinking
Eddie,
who
was
active
in
the
report
there
and
he's
someone
who
originally
set
it
up,
so
maybe
if
he
can
find
yeah
I,
know
ready
yeah,
he
might
be
able
to
know
something,
because
he
did
a
lot
of
research
into
this
in
the
initial
days
and
for
the
integration
tests
like
like.
Can
we
make
sure
like
we
do
have
targeted
tests
which
cover
these
ones
so
that
it
won't
be
like
a
accidental
thing
that
we
hit
this
code
path.
C
So
that's
the
I
kind
of
wanted
some
feedback
on
that.
So
I
can
absolutely
like.
We
have
this
in
my
other
product
that
I
work
on.
We
have
some
tests
that
just
use
reflection
and
hit
every
possible
Event
Source
method
that
would
increase
coverage,
and
then
these
sorts
of
things
would
go
away.
However,
if
it's
something
we
want
to
investigate
like,
maybe
it's
noteworthy
that
some
of
our
tests
are
randomly
throwing
exceptions.
B
C
Oh
yeah,
so,
oh
that's,
that's
two
different
ways
to
to
fix
it.
So
I
was
thinking.
I
could
write
a
reflection
test
that
just
causes
every
Event
Source
method
that
would
make
that
there
disappear,
but
would
you
describe
finding
the
The
Source
class
and
if
it's
got
like
a
try
catch
and
then
invoking
that
during
a
unit
test,
yeah
I
absolutely
agree,
that's
something
we
should
do
and
that's
what
I've
been
doing
is
my
PR's
already,
but
in
some
instances
it's
harder
than
others.
C
It's
like
for
one
I
I
did
throw
an
exception,
but
it
was
actually
like
handled
somewhere
else.
So
I
couldn't
test
one
class's
exception
handling
because
it
was
just
captured
like
another
level
down
so
I
I
think
both
targeting
it
from
both
directions
would
be
a
great
thing
to
do,
and
that's
what
I'm
planning
to
do
in
the
yeah.
B
It's
very
unlikely
that
we'll
get
100
like
we'll
settle
at
around
98
97.
Like
absolutely
sorry.
So,
if
you
have
like
very
small
things,
limited
that's
Property
Management
would
be
worth
chasing
to
reach
that
100
percent
and
the
new
cell
integration
just
like
here
like
do
you
mean
the
one
which
we
call
integration
test,
because
we
have
a
few
things
which
we
call
integration
test,
which
means
up
like
containers
for
the
test.
B
Apps,
we
run
that
inside
the
container,
like
I,
think
the
most
common
one
is
the
SQL
entries
where
we
want
to
spin
up
a
radius
and
SQL
instance.
So,
instead
of
the
one
you're
calling
as
integration
test
or
are
you
coding
or
pretty
much
like
things
like
I,
think
even
SP
net
code
tests
can
be
considered
integration
test.
C
Yeah
I
was
using
it
just
as
a
generic
term.
The
top
part
is
that
code
coverage
doesn't
give
me
any
clue
or
hint
as
to
what
like
individual
test
was
run
that
caused
this
variability,
because,
if
that,
if
that
was
available,
I
could
go
track
it
down
and
like
hey.
Why
is
this
one,
but
why?
Why
is
this
happening?.
B
Yeah
anyway,
thanks
for
the
investigation,
I
think
we
should
like
be
able
to
like
fix
some
of
them
and
if
we
can
get
Eddie
or
someone
else
to
help
with
the
code
coverage
part,
then
we
might
see
the
list
now
is
here.
This
was
always
like
a
known
issue
like
we,
you
submit
appear,
and
it
shows
that
you
broke
something
in
C
pages
right,
that's
very
odd,
for
that's
why
we
disabled
it
from
being
a
record
chip.
B
C
Nope,
that's
it
I
just
wanted
to
share,
and
you
know,
inform
everybody
what
I
was
looking
at.
B
B
C
C
You
can
go
to
I
can
share
it
in
the
chat.
Oh
yeah
different
coverage
website,
yeah.
B
Okay
and
like
this
is
something
which
we
have
set
up
long
back.
We
have
set
up
like
or
I,
don't
know
whether
we
need
like
any
special
permission.
Oh
okay,
probably
something
which
I
have
to
expect
because
I
just
reinstalled
my
machine
time,
I
may
not
have
logged
into
all
the
places.
I
say
usually.
B
Okay,
anyway,
thanks,
let's
move
to
the
next
items
in
the
agenda,
unless
anyone
else
have
more
comments,
thoughts
to
share
about
code
coverage,
all
right,
let's
go
to
the
next
one.
Okay,
I
can
open
this
issue.
What
was
the
thing
which
we
want
to
yeah
vishwash?
Can
you
go
ahead.
A
Yes,
yeah,
so
I
I
wanted
to
discuss
the
possibility
of
removing
the
net
standard
targets
from
the
asp.net
core
instrumentation,
the
reason
being
we
already
Target
net
6
and
Net
7
now
in
there.
So
I
just
wanted
to
understand
if
there
is
any
specific
need
to
have
net
standard,
2.0
and
2.21
as
well
as
we
started
both
of
them,
so
I
added
a
link
to
the
recommendation
from
the
at
the
docs.
A
So
the
last
paragraph,
if
you
see
in
the
reusable
libraries
it
says,
if
you
don't
need
to
support.net
framework,
you
could
go
with
netsigner
2.1
or
net
five
six.
But
the
recommendation
is
to
you
skip
next
standard
paper
one
and
go
straight
to
Netflix.
So
just
just
wanted
to
understand
like
if
there
is
any
use
case.
We.
B
Used
to
have
that
use
case
earlier,
which
may
not
be
true
anymore,
because
we
did
need
net
2.0
I
think
we
even
had
a
Net
Framework
Target,
because
it
was
possible
to
write
asp.net
core
applications
which
targets.net
framework,
like
you
start
from.net
new
application.net
core.
So
it
will
look
like
the
new
model
in
Sp
net
core,
but
the
target
framework
would
be
like
actual
net
four
seven
or
net
four
six,
but
I.
B
Don't
think
we
need
to
like
keep
supporting
it,
because
this
that's
something
which
was
not
even
supported
by
asp.net
core
in
the
latest
version,
I
think
starting
with
3.1.
That
is
no
longer
the
case.
B
There
is
no
dotnet
framework
version
of
sp.net4,
so
with
that
I
think
we
should
be
able
to
remove
the
net
standard
one,
even
though,
like
one
concern
I
think
Allen
was
replacing
earlier
that
if
this
library
is
referenced
by
a
user
in
a
like
a
shared
Library,
which
is
targeting
next
standard,
then
I
don't
know
whether
we
would
cause
the
many
issues
like,
for
example,
if
a
user
is
having
a
shared
wrapper
library
and
that
rapper
is
supposed
to
work
with
dotnet
framework
and
Dot
net
core,
so
they
tend
to
Target
next
and
a2o,
and
that
shared
Library
wants
to
add
a
dependency
on
this
package.
B
So
in
that
case,
whether
we
bind
correctly
or
not,
that's
something
I
do
not
know
it.
Alan
did
mention
like
something
like
that
in
a
few
weeks
back,
but
that
is
said,
I
don't
see
any
recent
for
us
to
have
anything
other
than
these
two.
B
That
he
won't
be
here
yeah.
You
can
check
with
him
offline
whether
whether
that
scenario
was
like
actual
like
something
which
we
need
to
work
on,
or
can
we
just
simplify
by
supporting
six
and
seven
and
when
six
goes
after
support
next
year,
we'll
just
like
remove
it
and
keep
seven
and
add
eight.
If
we
need
to
add
eight
I
mean
if
you
want
to
access
something
specific
from
eight,
we
need
to
add
that
Target.
Otherwise
we
don't
need
to.
It
will
just
work.
Fine.
B
Yeah
is
this
like?
Oh,
can
you
open
the
issue
here
like
with
this
link
because
it's
otherwise
it's
going
to
be
difficult
to
find
this
from
the
meeting
node?
So
if
you
can
open
an
issue,
describe
this
indent
in
some
explanation
or
why
you
want
to
do
it
and
is
this
specifically
for
SB
net
core,
or
are
you
considering
doing
it
for
like
other
things
like,
for
example,
HTTP?
Do
we?
How
do
you
know
if.
A
B
So
what
like,
by
doing
that
in
SB
net
core
we'd,
certainly
gain
certain
advantages
right
right!
Sorry,
not
Prometheus!
Let
me
open
the
instrumentation,
so
if
you
just
have
6
and
7
Target,
then
we
can
always
assume
we
have
access
to
the
SP
net
core,
app
and
I.
Think
that
would
probably
simplify
a
lot
of
stuff
in
the.
A
Yeah,
so
we
don't
need
to
do
the
reflection
like
right
now,
if,
if
we
have
those
targets,
I
think
we
will
have
to
have
like
one
of
the
issues
that
I
have
opened
is
to
avoid
the
reflection,
because
all
these
types
are
public
and
we
should
be
able
to
just
use
them
as
it
is
without
doing
the
reflection
so
like.
If
we
continue
targeting
that,
then
we
have
to
have
the
special
cases
for
internet
standard
yeah.
B
And
that
would
really
solve
one
issue
which
we
were
long
long
wanting
to
solve.
The
signature
of
entries
and
filter,
which
is
currently
like
object,
object
like
it's
all
like
objects,
so
we
expect
people
to
do
the
East
check,
but
we
could
improve
the
signature
to
have
it
like
more
strongly
typed
to
make
it
like
really
easy
thing:
a
planche.
D
Yeah
I
have
a
lot
of
thoughts
on
this
Alan
and
I
have
been
talking
on
and
off,
but
a
lot
about
net
standard
and
there's
that
issue
open
about
runtimes
packages
breaking
or
emitting
warnings
now
for
net
standard.
If
you
target
a
runtime,
that's
out
of
support,
if
we
just
across
the
board,
dropped
net
standard,
it
would
eliminate
all
those
build
problems.
D
D
D
B
D
We
just
dropped
net
standard
from
our
repo,
obviously
they
would
all
break,
and
so
what
they're
looking
at
is
they
would
have
to
go
into
those
projects
and
add
a
Net,
Framework
Target
and
then,
whatever
net
core
or
just
net,
they
want
to
Target.
So
their
net
standard
2o
becomes
net
four
six
two
and
you
know
net
six
or
net
7..
D
Then
you
probably
have
to
add
you
know
a
lot
of
preprocessor
stuff,
anytime
you're
using
different
apis,
but
they're
probably
going
to
realize
that's
what
they
need
to
do
anyway,
because
the
net
standard
2o
is
going
to
start
emitting
warnings
in
all
their
net
core
pipeline,
so
we'd
be
kind
of
forcing
that
decision,
but
I
think
it's
kind
of
inevitable.
That's
sort
of
what
Alan
and
I
are
discussing.
C
D
So
there's
probably
going
to
be
a
lot
of
people
complaining
when
this
drops
I,
don't
know,
we've
gone
back
and
forth.
Neither
of
us
has
a
solution.
It
feels
kind
of
inevitable
to
drop
net
standard.
So
maybe
we
should
just
do
it
on
this
particular
discussion
in
the
asp.net
core
stuff.
I
think
it
makes
a
lot
of
sense.
The
H
and
ecbc
clients
is
a
little
less
clear.
D
One,
that's
the
asp.net
core
I.
Don't
think
you
can
really
use
that
effectively
on
that
framework
anyway.
So
I
think
it's
safe
there
to
drop
the
net
standards
if
we
drop
it
from
HTTP,
client
I.
Think
that'll
upset
more
people
because
there's
valid
cases
to
use
that
on
that
framework
and
all
the
net
cores.
B
D
B
Okay,
okay,
so
at
least
one
thing
is
clear:
is
we
can
start
with
SP
net
core
and
we'll
probably
have
to
like
spend
more
time
and
like
seeing
the
impact
before
we
can
remove
it
from
other
one,
especially
the
chorus
detailing
course.
Tk
would
be
the
most
commonly
most
popular
one,
so
we
may
have
to
stick
with
net
standard
there
yeah,
even
though,
like
we
don't
really
support
netcore
3.1.
D
It
doesn't
make
a
lot
of
sense
for
us,
particularly
because
the
reason
to
Target,
net
standard,
20
or
2-1
is
really
to
include
like
mono
and
the
other
runtimes,
but
I
don't
think
we
work
on
those
today
anyway,
just
because
we
do
a
lot
of
dynamic,
Cogen
I,
don't
think
that's
supported
on
those
platforms,
I'm,
not
sure,
but
just
to
Target.
In
that
framework,
we
can
just
add
those
targets.
B
B
But
like
most
of
the
things
which
blocks
us
from
being
used
in
the
mono
or
other
targets,
we
should
be
able
to
like
work
around.
If
there
is
enough
Demand
right
I
mean
all
the
IL
stuff,
we
should
be
able
to
get
rid
in
the
next
version.
D
B
Yeah,
the
instrumentation
libraries
may
have
the
like
reflection,
hacks,
but
the
core
SDK
should
still
be
able
to
be
used
in,
like
all
those
scenarios,
if
you
remove
all
the
like
IL
code
and
stuff,
okay,
yeah
so
like
you
should
like
keep
I
think
you
can
proceed
with
removing
it
from
the
ASP
Network
instrumentation
and
let's
come
back
to
the
topic
of
whether
we
should
remove
it
from
the
SDK
to
a
later
stage,
when
we
have
more
confidence,
because
even
the
data
we
challenge
shared
is
like
from
today,
it's
which
is
like
approximately
for
four
and
a
half
months
before
dot
net
core
3.1
is
going
out
of
support.
B
So
maybe
this
might
look
a
lot
different.
When
we
reach
closer
to
the
actual
dot
net
core
3.1
end
of
life,
maybe
it
will
drop,
we
will
see
how
it
goes.
Foreign.
B
We
are
still
targeting
at
standard
two,
and
if
user
is
on
dot
net
core
3.1,
they
will
get
that
like
build
warning.
It
used
to
be
breaking,
but
now
it's
just
a
warning,
so
people
can
choose
to
ignore
it
and
move
on
thing.
That's
probably
the
least
disruptive
thing
we
can
do
so
people
can
continue
to
use
if
they
want
to
foreign.
B
Move
to
more
complex,
even
more
complex
topics,
all
right,
yeah
plans-
you
can
discuss
the
Builder
issue.
If
you
want
you
can
share
I,
can
stop
sharing.
D
A
A
D
So
what
I'm
working
on
is
this
dependency
injection
stuff
for
tracing,
which
is
really
the
Tracer
provider
Builder,
so
I'm
moving
some
of
the
stuff
we
had
in
the
hosting
Library
package
into
SDK,
because
in
SDK
we
now
have
service
collection.
We
have
all
the
stuff
we
need,
which
we
didn't
originally,
that
all
came
in
with
logging,
so
I
have
it
working
really
well
really
great
for
what
I'm
kind
of
calling
the
attached
paces.
D
So
in
the
sdk.crate
Tracer
provider,
Builder
method,
which
is
sort
of
you,
want
to
just
build
your
own
provider
you're
not
going
through
the
hosting
package.
You
now
can
configure
services
and
use
dependency
injection.
You
can
do
all
the
stuff
that
previously,
you
could
only
do
with
the
hosting
package,
which
allows
you
to
author
extensions
and
libraries
that
also
do
that
stuff.
So
you
can
now
make
a
library
that
targets
just
SDK
that
people
can
consume
and
then
use
end.net
core.net
framework.
However,
they
want
the
same.
D
D
There
are
cases
where
you
might
not
want
to
do
that.
Where
you
want
to
be
detached,
the
cases
are
sort
of
what
app
insights
does
where
you
can
have
like.
Imagine
you
have
some
big
Enterprise
application
in
your
startup?
You
don't
want
to
have
knowledge
of
all
the
stuff.
All
your
libraries
are
doing.
You
might
want
to
delegate
to
like
I.
Don't
know
your
messaging
Library,
you
know
it
owns
all
its
dependencies
and
its
open
telemetry.
D
So
if
you
were
attached
to
the
Builder
you
would
have
to
in
this
code,
you
know
register
your
stuff,
so
what
I'm
trying
to
do
is
solve
for
sort
of
this
detached
case.
What
that
might
look
like
is
here's
sort
of
like
a.net
framework
style.
This
is
an
application
that
does
not
have
the
hosting
package,
so
I
can
hold
on
a
second,
my
kids
crying.
D
D
D
So
here's
here's
a
more
pristine
example
of
what
this
might
look
like.
So
here
is
my
open.
Telemetry
setup
looks
pretty
standard
here:
I'm
just
registering
some
service.
So
what
this
service
is
able
to
do
now
on
this
new
kind
of
pattern,
it
can
register
its
own
dependencies
and
then
it
can
re-enter.
Add
open,
Telemetry
tracing.
D
So
previously
this
call
would
like
generate
a
builder
every
time
you
called
it
now,
I
have
it
so
you
can
re-enter
it.
Every
re-entrant
call
is
just
configuring,
the
same
Builder,
which
will
lead
to
one
provider
for
that
service
collection.
So
you
can
now
detach
all
your
configuration
so
that
kind
of
makes
sense
what
the
goal
is.
B
Yeah
I
mean
maybe
you
can
describe
how
this
aligns
with
what
asp.net
code
login
does
already
like.
If
you
do
like
build.it
logging
like
10
times
it
doesn't
add,
like
10
factories,
it's
still
attached
to
the
same
thing
so.
A
D
D
Let
me
do
it
over
here,
the
without
hosting
it's
a
bad
example
too.
You.
A
D
That's
not
a
good
example,
because
they're
all
is
rude.
Yeah.
D
D
Calling
add
twice,
but
these
they're
not
really
true
ads.
The
Builder
that
you
get
returned
is
just
a
wrapper
over
the
service
collection.
So
all
these
things
are
doing
are
registering
services
that
get
fed
into
the
logger
Factory.
So
even
though
I'm
calling
add
twice
here,
I'm
just
going
to
get
one
logging
Pipeline
and
it's
going
to
have
two
providers
in
it.
B
Yeah
and
any
configuration
we
do
would
be
like
applicable
to
all
of
them
like
there
is
some
logging
configuration
which
should
be
like
equally
applied
to
all
the
providers.
D
So
I
have
the
same
pattern
now
in
all
of
this
code,
so
anybody
at
any
time
can
call
add
open,
Telemetry
tracing
and
configure
the
same
Builder
the
same
provider
so
that
works
really
well
for
Library
authors
or
you
know
in-house
applications
that
just
want
to
split
it
up
all
over
their
libraries.
It
works
well.
The
problem
is,
this
extension
method
lives
in
the
hosting
Library.
D
So
what
I'm
trying
to
do
is
figure
out
some
way
to
solve
this
with
some
Elegance,
so
what
I
originally
had
is
you
can
just
throw
into
the
service
collection
a
configuration
callback
delegate
which
will
just
give
you
the
Builder,
so
this
could
work.
This
doesn't
need
anything
from
hosting.
It's
just
not
super
friendly
right.
This
is
pretty
nasty,
so
I
get
people
don't
like
this.
D
I
think
that's
kind
of
the
natural
thing
to
do
so.
I
have
that.
So
what
I
did?
What
I
did
in
the
SDK
is
add
a
configure
open,
Telemetry
tracing
extension,
so
that
you
can
do
precisely
that.
Okay,
if
you
only
have
an
SDK
reference,
you
can
call
this
guy
and
it
works
exactly
like
you
would
expect
the
problem
with
that
is.
D
It
introduces
this
path
where
back
over
here,
where
I
have
hosting
or
I
may
not
have
hosting,
but
I'm
an
asp.net
core
app,
let's
say
I,
add
the
SDK
I,
don't
know
about
hosting
or
I.
Don't
do
enough.
Research
I
just
take
the
SDK
and
I
use
intellisense
and
I.
Configure
myself
like
this
I
go
okay,
there's
this
open
Telemetry
extension
called
configure
open,
Telemetry,
so
I
stitch
up
my
application,
calling
this
guy
and
then
I
expect
it
to
work.
D
This
won't
do
anything
because
it
doesn't
actually
start
the
Tracer
provider.
The
only
difference
between
configure
open,
Telemetry,
tracing
and
add
open,
Telemetry
tracing
is
the
ad
guy
registers.
This
hosted
service
and
all
that
thing
does
is
basically
onstart
access,
the
provider.
So
then
it's
it's
in
memory.
It's
attached
everything's
up
and
running,
so
really.
The
only
difference
between
configure
and
add
is
that
one
line
of
code,
but
unfortunately
this
I
hosted
service
lives
in
the
hosting
abstractions,
so
that
is
kind
of
the
problem.
D
B
A
B
And
there
is
I
mean
we
do
not
have
any
other
way
to
other
than
adding
the
hosted
service.
We
do
not
have
any
way
to
like
reliably
trigger
someone
coding,
the
Tracer
provider
and
like
like
trigger
all
the
building
of
the
pipeline,
so
yeah.
D
D
B
B
Extra
package-
that's
the
that-
makes
the
life
of
end
users
truly
easy.
Yes,.
A
It
is
I,
wouldn't
check
what
it
has.
It's
kind
of
kind
of
got
a
bunch
of
nonsense,
something.
D
This
stuff's
already
pulled
in
I
think
by
diagnostic
Source
yeah
they're,
already
getting
configuration
in
the
SDK
they're
already
getting
dependency
and
extractions
in
the
SDK.
This
might
just
be
the
one
strange
one
that
we
would
force
onto
net
Frameworks,
but
it
would.
It
would
solve
a
lot
of
problems
and
it
would
basically
allow
us
to
completely
deprecate
an
end
of
life,
the
hosting,
because
it
really
doesn't
have
anything
after
these
changes.
All
it
has
is
this
basically
startup
guy.
D
B
You
or
like
we
could
ask
people
to
well,
no
sorry
that
won't
work,
they
I
mean
in
application
sales.
What
we
did
was
like
we
asked
people
to
manually,
go
and
ask
the
Tracer
provider
from
the
service
provider
themselves,
so
it
like
they
kind
of
trigger
it.
Instead
of
the
background
service,
we
added,
but
that
would
look
very
awkward.
B
B
I
started
working
on
this
trip
for,
like
probably
my
first
week
or
so
so
I
assumed
that
if
he
already
concluded
that,
then
it's
very
unlikely
that
we'll
be
able
to
find
anything
new
because
he
consulted
the
people
who
own
SP
net
core
hosting
packages,
and
this
was
like
reviewed
by
them
as
well.
At
that
time
very
first
time
we
added
this
package,
so
there
is
very
unlikely
unless
we
find
like
some
really
crazy,
hacky
way,
the
natural
ways
to
have
that
hosting
thing.
B
D
B
So
what
can
you
show
the
like
example
use
case
program
with
hosting
and
without
hosting
once
more
just
to
see
like?
What's
the
awkwardness
part
which
we
want
to
remove.
D
So
the
concern
I
have
with
having
configure
in
the
SDK
and
add
in
hosting,
is
people
doing
asp.net
core
applications,
they're,
probably
going
to
go,
add
an
SDK
reference
and
then
they
might
just
start
typing
code
and
all
they
would
see
you
know
if
they
do
Services
Dot,
they
won't
see
ad
unless
they
have
hosting
they'll
only
see
configure.
So
they
might
just
think
naturally,
okay.
This
is
what
I
call.
They
might
do
this
pattern
and
then
they're
going
to
wonder
why
they
never
see
Telemetry
nothing
works.
Can.
B
You
again
remain
like
what
was
the
thing
which
prompted
us
to
add
configure
in
the
SDK.
You
had
an
example
which
prompted
us
to
add
the
extension
method
on
the
SDK
itself
for
configure
open,
Telemetry
tracing.
D
So
I
originally
added
it
for
the
case
of
like.net
framework,
or
you
know,
you're
a
library,
author
and
you
want
to
build
some
extension,
so
you
reference
SDK,
you
could
reference
hosting
there's.
No
reason
why
you
couldn't
do
that,
but
I
think
it's
just
kind
of
natural
to
only
do
the
SDK
like
if
you're
a
library,
why
would
you
have
a
dependency
on
hosting
right,
it's
kind
of
weird
yeah?
So
it's
basically
this
case
where
I
want
to
build
foreign
library
that
registers
some
services
and
configures
open
telemetry
with
an
SDK
reference
without
posting.
D
B
B
B
Totally
yeah,
even
the
library
can
this
add
message
service
could
be
an
extension
method
on
the
Tracer
provider
Builder.
So.
D
B
I
think
that's
like
a
reasonable
trade-off,
because
if
you
are
writing
a
library
and
you
could
use
the
Tracer
provider,
Builder
extension
method
to
configure
your
stuff
into
the
overall
pipeline
or
if
you
choose
you
want
to
do
it
the
DI
native
way,
then
you
ADD
extension,
start
hosting
package
and
call
like
a
resource.addup
and
Telemetry
tracing
and
configure
your
thing
inside
that
and
we'll
take
care
of
merging
that
all
and
building
the
final
thing.
E
He's
in
the
car
I've
been
dropping
loads
of
notes
in
the
chat,
but
I
don't
talk
because
they
I'm
on
the
train,
so
I'll
probably
cutting
it
out,
but
I've
been
dropping
loads
of
stuff
in
the
chat.
A
B
About
a
second,
let's
see,
yeah
you
had
to
come
in
about
the
name
and.
B
B
I
think
he's
referring
to
the
fact
that
if
you
duplicate
the
extension
stored
hosting
absoluting
it
in
favor
of
having
everything
in
HTTP,
that's
probably
the
only
thing
we
see
like
even
mentioned
about
breaking.
D
D
B
Yeah
well,
one
additional
thing
we
want
to
check
is
because
when
we
took
the
decision
to
take
a
dependency
on
Microsoft
extension
slogging,
we
got
the
confirmation
from
the
dotnet
runtime
owner
said
they
treated
spcl
package,
so
it
won't
have
breaking
change.
We
don't
know
whether
it's
a
true
it's
true
with
the
hosting
service
as
well.
B
It
could
be,
but
we
need
to
like
be
absolutely
sure
that,
like
there
won't
be
any
breaking
changes
with
every
measure
version
release,
because
we
kind
of
have
that
Assurance
from
diagnostic
source
and
extensions.looking
ever
since
they
were
pulled
into
the.net
runtime
package,
not
when
they
were
originally
part
of
asp.net
core,
so
that
I'm.
A
D
To
follow
what
Martin
is
saying,
if
a
breaking
change
isn't
killing
off
the
hosting
library,
then
what's
what's
the
breaking
chain,
do
you
think
would
solve
this.
E
I'll
try
and
talk
if
I
cut
out
sorry,
the
breaking
change
would
be
removing
ad
open
Telemetry
from
hosting
into
the
base
package
and
changing
what
the
hosting
package
does,
whether
we
have
to
deprecate
it
and
stick
in
ASP
net
core
hosting
package,
which
uses
hosted
service
or
something
like
that.
But
what
you
wanted
to
do
just
move
that
ad
open
telemetry
straight
back
into
the
into
the
SDK.
E
D
D
D
D
So
if
you're
setting
up
an
application,
you
take
a
reference
on
SDK.
You
go.
Oh
great.
There's
this
ad
call
I
Stitch
it
up.
I
launch
my
service,
nothing
works,
so
you
would
have
to
somehow
discover
that
the
reason
it's
not
working
is
you're
missing.
This
auto
start,
which
I
felt
like
didn't,
really
solve
anything.
E
I
think
I,
adding
it
to
the
service
collection
directly,
might
work
or
something
like
that,
but
yeah
I
agree,
there's
something
a
little
bit
weird
about
it.
I've
sent
you
some
things
on
slack
of
ideas,
but
I
I,
don't
think,
there's
an
easy
answer.
D
E
B
E
Yeah,
if
you
think
about
the
types
of
apps,
though
we've
got
ASP
at
core
doing
an
app.use
is
a
pre-established
plan.
D
D
B
You
also
had
another
suggestion
to
like:
do
it
like
in
two
phases
like
in
the
service
collection.
You
add
things
and
when
you
have
the
app
by
building
the
hosting
you
call
like
app.use,
open
telemetry.
That
could
be
the
thing
which
can
trigger
off
things.
B
A
B
That
would
work
if
you
look
at
our
asp.net
core
example
for
Prometheus.
It's
mostly
like
that.
You
first
add
open
Telemetry
with
Prometheus
exporter
and
they
need
your
middleware.
You
have
to
configure
okay
use,
Prometheus
endpoint,
so
it's
like
two-step
and
it
like.
If
we
agree
that
that's
a
reasonable
thing
to
do,
for
people
who
are
in
asp.core,
then
we
can
solve
this
problem.
B
It
means
that
you
have
to
do
like
two
things
instead
of
one,
but
it's
not
that
off
from
what
we
anyway
ask
people
for
metrics
in
Sp
net
code
for
Prometheus,
and
it's
similar
to
what
many
of
the
building
things
like
work
like
you
had
MVC
to
the
DIA,
and
then
you
use
the
application
Builder
to
use
MPC
pattern.
So
it's
not
that
awkward.
This
pattern,
it's
definitely
better
than
like
that
auto
start
or
anything
else
thing
which
we
want
to
do.
B
A
B
Looks
like
less
awkward,
whether
it's
fully
neat
or
not.
That
I
mean
because
in
applications
such
it's,
a
one-liner
thing
in
158
is
all
you
need.
You
don't
need
the
second
part,
but
that's
just
the
way
application
insights
work.
We
don't
really
have
any
reason
to
make
it
work
the
same
way
as
application
says
it's
just
one
product,
but
this
is
where
we
could
get
some
help
from
neck
other
vendors
as
well,
whether
whether
they
see
that
as
a
problem
or
they
think
this
is
okay.
B
B
And
if
at
all,
we
are
breaking
now,
it's
only
time
to
play
because
it's
still
like
not
stable.
So
if
you
have
a
chance
to
break
now,
is
the
time.
B
B
Yeah,
this
is
a
comment
right
like
at
least
like
for
people
who
use
asp.net
core,
like
adding
things
to
bi.
In
I
mean
it
was
like
more
obvious
in
the
dotnet
5
template
or
maybe.net
3.1
template.
You
had
configure
services
and
configure.
So
it's
like
you
had
like
two
separate
methods
in
your
startup,
where
you
add
things
and
you
configure
things,
but
now
it's
like
merged
into
a
single
class,
but
still
you
are
conceptually
doing
the
same
thing.
B
You
do
things
to
do
Di
and
then
you
configure
your
actual
app
before
you
called
app.run.
So
it
still
feels
like
natural
to
me,
though:
I'm
not
like
an
expert
in
the
way
like
asp.net
core
users
are
used
to
seeing
things
yeah.
Let's
see
how
the
feedback
was.
We
can
like
probably
take
like
some
iterations
on
it
in
the
next.
Let's
still
call
it
like
alpha.2
the
next
release
with
this
feature
and
see
how
is
the
general
feedback
and
based
on
that,
we
can
decide
further.
B
Okay,
yeah
I
think
we
are
right
on
time,
so
we
can
continue
this
discussion.
So
one
thing
to
add
is
like
whatever
release.
We
do
next
will
be
still
another
Alpha,
because
we
still
have
a
lot
of
rough
things.
So
it's
not
yet
good
to
call
it
as
a
beta.
So
it
should
be
fine,
just
keep
it
yourself
and
then
I,
try
it
and
get
some
feedback
and
then,
once
once
we
have
a
good
confidence
that
this
is
going
to
stick.
Then
we
can
start
with
the
beta
naming.
A
B
All
right
thanks,
everyone
see
you
again
next
week
and
if
you
have
comments
on
like
the
configuration,
please
drop
a
comment
in
the
pier
which
plans
already
has
it's
it.
I
would
say
it's
very
complex
to
digest
so
take
some
time,
but
that's
the
way
it
is.