►
From YouTube: Open Telemetry's Personal Meeting Room
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
D
D
D
B
D
A
Let's
look
at
the
unshit
so
from
our
last
sick
meeting.
I
think
we
we're
looking
at
these
two
would
probably
could
probably
be
made
internal.
We
were
about
to
having
branch
is
going
to
explore
on
that,
and
so
Blanche
I
was
also
looking
at
the
pr
that
you
had
submitted
to
update
the
docs
and
I.
Had
one
question
that
I
thought
I'd
ask.
First
before
we
start
reviewing
the
other
apis
that
we've
added
so
foreign.
A
D
E
I
mean
there's
two
reasons:
it's
shown
in
this
sample,
this
one's
actually
registering
a
Singleton,
so
that
has
to
happen
against
Services
kind
of
at
the
bottom
there,
where
your
mouse
just
was
the
last
line,
yeah
right
there,
so
that
is
registering
a
Singleton
service
which
then,
if
you
go
below
that
I
think
I
have
the
Constructor,
like
demo
code,
see
how
it's
in
the
Constructor
it
has
a
second
parameter.
E
B
E
I
had
it
originally,
but
the
problem
there
is,
if
you
look
at
the
very
top
of
the
little
box
before
it
Clips
off
there
nope,
he
lost
it.
That's
the
first
line
in
the
configure
Builder
too
many.
We
don't
have
line
numbers
on
this
snippet
scroll
up
a
little
bit
see
how
it's
getting
the
options
right
there
by
name.
E
B
E
You
have
a
couple
options.
You
could
inject
the
I
options
monitor
and
then
call
the
get
operation
to
get
your
named
options,
but
then
you
also
need
to
somehow
inject
the
name
of
the
options
that
you
need,
which
itself
is
non-trivial,
so
I,
don't
exactly
know
how
many
even
do
that
I'm
just
kind
of
assuming,
in
this
case
my
Custom
Service
as
a
Singleton.
It
just
doesn't
support
named
options.
It
just
gives
you
like
one
universal.
It
uses
the
default
instance.
E
E
So
if
we
just
invoked
those
manually
here
on
the
final
instance,
it
would
work
for
the
purposes
of
our
code.
But
anybody
else
externally
saying
give
me
an
options.
Instance,
those
callbacks
wouldn't
fire.
So
there
was
an
issue
that
Travis
opened
up
for
Like
Jaeger
options.
He
ran
into
this,
so
the
correct
way
to
do
it
is
you
call
services
dot
configure
what
that
essentially
does
is
wrap.
The
delegates
in
an
interface
called
I,
configure
options
and
then,
when
somebody
asks
the
platform
give
me
options.
E
It
goes
to
this
thing
called
like
an
options
Factory,
which
knows
how
to
either
take
the
cached
last
one
that
was
created
or
it
will
new
one
up
and
then
it
runs
all
of
those
configurations.
There's
you
can
do
like
configure
all
you
can
configure
by
name
you
can
do
Post
configure.
You
can
register
validations,
there's
all
these
extension
points
into
the
options
API.
E
So
if
you,
if
you
scroll
up
a
little
bit,
Above
This
method,
I,
actually
added
some
guidance.
Keep
going
so
right
here
see
these
two.
Do
statements
I
tried
to
capture
all
of
that,
so
it's
in
that
code
snippet,
but
I
also
sort
of
explained.
Why
and
put
some
links
in
there,
hoping
that
if
anybody
is
authoring
these,
if
you
read
this
thoroughly,
there's
a
lot
of
information
here
but
I
try
to
explain
sort
of
the
intricacies
of
why
that
snippet
is
doing
what
it's
doing.
If
that
makes
sense,.
D
D
E
Good,
that's
weird
I
wonder
why
my
mic
just
died.
Where
did
where
did
I
cut
out.
A
No
I
think
I
I
asked
you
like,
so
this
configure
Services
is
essentially
providing
access
to
the
service
collection
for
any
library
or
any
like
component
right,
author,
that's
the
main
purpose.
E
E
Okay,
hopefully
this
is
stable,
so
those
two
methods
there
configure
services
will
configure
Builder.
Those
are
sort
of
the
two
fundamental
interfaces
that
everything
is
built
on
top
of.
So
when
you're
calling
like
ad
export
or
ad
processor
configure
resource,
that's
all
calling
configure
services.
So
it's
just
dropping
into
the
service
collection
sort
of
a
list
of
actions
that
we're
going
to
execute
when
we
actually
build
the
provider
so
that
all
gets
dumped
in
the
service
collection.
E
Then
the
host
builds
the
service
provider
and
starts
like
spitting
out
code.
That's
sort
of
phase
two:
that's
one
configure
Builder
files,
so
those
are
played
back
in
order,
so
we
register
all
this
list
of
stuff
and
then
their
fire.
These
configure
Builders
will
fire
in
that
phase.
At
that
point,
the
the
service
provider
is
ready.
The
services
are
closed.
You
can
no
longer
add
an
event.
So
that's
your
opportunity
to
then
actually
get
instances
of
things.
E
If
you
scroll
up
a
little
bit
so,
let's
say
the
user
calls
add
my
library
exporter
and
then
the
next
line
they're
doing
like
a
their
own
configuration
into
options,
so
they
could
register
like
validations.
They
could
register
some
post
actions
and
then
the
Tracer
provider
gets
built
or
the
hosting
the
hosted
service
creates
it.
Essentially
that
will
then
fire
phase
two
and
when
we
access
those
options
at
the
bottom
of
the
screen,
that
will
run
our
configurations.
E
A
Okay,
okay
and
we
need
these
extensions
for
eye
service.
I
mean
like
we
don't
need
it,
but
we
also
offer
this.
So
what's
the
like
benefit
of
having
an
extension
method
against
High
service
collection
versus
like
making,
everyone
extend
against
Tracer
provider,
Builder.
E
So
the
example
that
I
came
up
with
here
is
I
I
call
the
call
add
my
library,
pretend
that's
like
add
MVC,
so
the
user's
creating
their
application.
They
don't
even
really
know
Telemetry
is
happening.
They
just
want
to
add
NPC.
So
when
you
call
add
MVC,
it
registers
a
whole
bunch
of
services
right
it
does
its
own
options.
That
who
knows
who
knows
what
it
does
it's
doing?
It's
doing
magic,
it's
a
black
box,
but
it
might
also
want
to
register
its
meters
its
activity
sources.
It
could
also
set
up
all
the
Telemetry.
E
So
what
this
example
here
is
doing
is
kind
of
showing
that
so
add
my
library.
The
first
thing
it
does
is
it
it
sets
itself
up.
So
it
introduces
a
service
I,
my
library
service,
that's
what
the
user
is
going
to
actually
use.
That's
like.
Let's
call
it
like
a
service
bus
or
a
message
queue.
It
could
be
redis,
but
it's
also
based
on
its
options.
E
So,
instead
of
needing
to
make
three
different
calls,
so
if
you
did
it
the
traditional
way,
you'd
have
to
call
add
my
library
and
then,
when
you're
configuring,
your
Tracer
provider
you'd,
have
to
call
you
know,
add
my
library
instrumentation
when
you
configure
your
metrics
you'd
have
to
call
their
just
a
lot
more
calls.
This
method
allows
you
to
kind
of
do
one
level
higher.
So
without
those
providers
being
available,
you
can
build
extensions
that
just
kind
of
do
everything
for
you,
Auto
magically.
B
I
think
the
example
would
be
something
like
Entity
framework
that
has
currently
something
on
there.
That
says,
enabled
diagnostic
logs
there's
an
option
on
the
the
setup
of
adding
Entity
framework
by
the
service
collection.
B
B
To
do
that
add
source
and
add
meter
are
obviously
the
the
easy
ones,
but
some
of
them
could
do
something
a
little
bit
more
complicated,
so
they
might
want
to
do
something
that
augments
the
traces
based
on
parameters-
I,
don't
know,
but
it
means
that
they
don't
have
to
do
a
second
call
onto
the
Tracer
provider
builder.
In
order
to
add
those
things
they
can
just
do
it
inside
of
that
library
and
from
a
user
experience
perspective.
E
D
D
E
I
wrote
this
and
rewrote
this
and
kind
of
worked
with
Alan
I
feel
like
the
service
collection
pattern
is
really
good
for
instrumentation
and
then,
if
you
go
back
up
to
the
Tracer
one
I
kind
of
said,
this
pattern
is
better
for
like
components
like
if
you're
shipping,
a
sampler
or
an
export
or
something
that's
very
much
tied
to
tracing
or
metrics
like
one
or
the
other,
then
you
probably
want
to
Target
the
Builder,
the
provider
Builder.
If
you're
shipping
instrumentation,
which
is
sort
of
cross-cutting,
it
probably
touches
one
or
more
signals.
E
A
little
bit
of
gray
area
and
overlap,
so
it's
hard
to
say
we
kind
of
need
to
see
what
the
community
does
with
this.
But
multiple
people
have
asked
for
sort
of
this
detached
method.
Martin
is
the
most
recent
really
early
on
when
we
were
building
I
think
it
was
Eric
was
really
screaming
for
this
and
we
didn't
do
it,
but
it's
sort
of
a
community
pass
more
than
anything.
It's
not
strictly
required,
but
I
think
enough.
People
have
asked
for
it.
In
my
opinion,.
F
Even
if
you
do
not
do
this,
the
alternate
option
is
the
libraries
would
provide
extension
method
on
pressure,
Builder
and
meter.
Builder
and
user
are
user
should
call
like
all
of
them
like
one
by
one.
D
F
F
D
F
Like
if
I'm
writing
an
instrumentation
Library
like
which,
like
how
do
I
determine
because
we
have
a
different
section,
I
think
in
the
same
dock
like
somewhere
above,
we
have
a
guidance
for
instrumentation
Library,
oh
yeah,
can
you
go
to
the
very
end
of
that
building
your
own
instrumentation
library
and
scroll
down
like
third
step
yeah,
so
that
part
we'll
need
to
tweak,
because
now
previously
we
were
only
recommending
ADD
extension
method
on
Tracer
provider
Builder.
But
now
we
have
to
link
them.
F
If
you
have
XYZ
use
case,
then
consider
exposing
a
method
on
I
service
collection
as
well.
Yeah.
F
So
maybe
one
other
potential
refactor
is
we.
We
need
a
talk
which
is
not
specific
to
trace
or
metric.
It
should
be
like
one
level
above,
like
General
configuration
but
I,
think
that's
a
like
thing
which
we
can
handle
later
as
well.
So
the.
E
Whole
session
for
the
guidance
for
Library
offers
really
applies
to
well.
Definitely,
you
need
a
provider
Tracer
provider
and
then
once
we
can
get
that
logging
stuff,
it
will
apply
there,
so
it
would
suck
to
just
like
copy
and
paste
that
whole
thing
three
times
and
tweak
the
name
so
I
could
definitely
see
like
a
shared
the
way
our
docs
are
kind
of
structured
they're,
all
in
folders
specific
to
the
signals.
F
Yeah,
that's
a
like
future
thing
like
we
don't
need
to
block
any
release
or
anything
based
on
whether
we
have
a
little
bit
extra
like
duplicate
in
two
places,
or
we
put
everything
under
Trace.
That's
easily
a
dog
issue
which
we
can
address
later,
but
I
I
do
have
like
one
more
question.
So
if
I'm
writing
a
instrumentation
Library
I
am
generally
expected
to
take
a
dependency
on
the
open,
Telemetry
API.
F
Only
it's
a
bug
that
our
SP
net,
core
or
I,
think
HTTP
client
has
a
dependency
on
the
SDK,
but
like
typically,
we
only
expect
any
APA
dependencies.
So
would
they
need,
like
will?
Would
they
be
required
or
forced
to
move
to
an
SDK
dependencies
or.
E
The
methods
you
want
to
do
so,
can
we
look
at
the
pr
that
was
just
merge.
The
problem
all
of
a
sudden
there's
something
now
and
I
were
kind
of
chatting
about
us.
E
Mean
let
me
open
that
PR
PR
Link
at
the
very
top.
B
E
A
D
E
E
B
F
And
that's
not
an
issue
for
exporter
or
resource,
because
they
anyway
need
a
secret
dependency
for
instrumentation.
We
we
should
leave,
make
it
a
optional
thing
like
we
should
not
force
users,
they
can
just
leave
with
API
dependency
alone
and
optionally.
They
can
take
an
SDK
dependency
and
provide
like
more
advanced
things,
so
that
should
be
an
option,
because
the
spec
is
very
clearly
coding
out.
Instrumentation
Library
should
only
have
API
dependencies.
D
F
E
So
if
we
ship
it
as
is
and
later
we
want
to
put
this
on
aprs,
it
could
get
tricky
only
because
you
can
move
types,
you
can
move
a
complete
type
from
SDK
to
API,
but
you
can't
move
like
methods,
so
these
particular
extensions
live
in
classes
like
Tracer
provider,
Builder
extensions,
that's
the
type
and
there's
a
whole
bunch
of
methods
in
there
that
we
probably
wouldn't
want
to
move
we'd
only
want
to
move,
like
certainly
fundamental
things.
E
So
if
our
plan
is
at
some
point
to
move
this
stuff,
I
could
redo
it
and
drop
in
some
some
classes
that
are
just
additional.
That
really
don't
need
to
be,
but
would
just
allow
us
that
flexibility,
it's
it
wouldn't
be.
A
hundred
percent
like
I,
could
take
my
best
guesses,
but
then,
when
we
actually
go
to
do
that
work,
if
you
miss
anything,
it
could
get
really
tricky.
D
E
The
millions
of
people
using
stack,
exchange
reddits
that
are
not
using
open,
Telemetry
they'd,
be
very
surprised
if
those
assemblies
like
just
started
showing
up
but
I
kind
of
expect
to
happen
is
I
would
like
to
see
happen
is
that
exchange
risk
goes
in
their
code
and
they
add
activity
sources
and
meters
using
the.net
API,
because
they
don't
need
to
do
what
to
do
that.
Then.
D
E
Would
expect
them
to
ship
a
package
like
stack,
exchange.redis.open
Telemetry,
which
has
the
extensions
to
register
it,
and
if
they
do
that,
I
don't
really
see
an
issue
with
them,
taking
a
dependency
on
the
SDK.
That
will
be
like
a
top
post
thing
yeah.
So
it
may
not
be
a
problem
to
keep
all
this
on.
Sdk
I,
don't
know
it's.
We
have
to
just
kind
of
see
what
happens.
F
Yeah
the
example
you
give
make
perfect
sense
to
me,
because
we
have
seen
like
many
libraries
attempting
to
do
exactly
that
in
their
core
Library.
They
don't
take
any
dependency
other
than
the
diagnostic
source,
and
if
users
want,
they
can
simply
add
the
name
of
the
meter
or
Source
period.
C
Don't
I
really
don't
know
how
common
this
is
going
to
be,
especially
for
for.net,
but
I
think
that
an
argument
that
you
may
get
against
that
is
so
great.
We
have
an
open
Telemetry.
You
read
us
instrumentation,
separate
package.
It
takes
an
SDK
dependency,
but
one
of
like
the
core
premises
of
the
architecture
of
the
API
SDK
split
you
know
by
the
spec-
is
that
the.
C
F
C
Yeah
100
no
yeah
I
understand
that
I
mean
I,
guess
it's
just
kind
of
like
and
and
that
maybe
is
fine.
So
it's
just
like
a
thing
that
kind
of
like
bootstraps
thing
or
like
configures,
it's
specific
to
our
SDK.
You
know:
that's
just
that's
just
an
acknowledge
limitation
I'm.
Just
saying
like
similar
to
the
the
architectural
approach
of
that
the
spec
has
taken.
You
know
we
could
take
that
approach.
I,
don't
know
that
we
should
like
I'm
not
making
an
argument
for
this
I'm.
Just
saying
like.
F
See
if
it's
a
little
like
any
customer
like
we
just
say
like
let's
say
we
are
meeting
with
these
folks
and
asking
them
to
instrument
like
they'll,
be
just
instrumenting
using
the
diagnostic
Source
APA,
and
they
don't
have
any
obligation
that
I
mean
the
customers
do
not
have
any
obligation
that
they
use
our
SDK
the
officially
want
if
they
support
a
completely
different
SDK.
That
should
work
just
fine,
but
the
special
configuration
on
like
service
collection,
yeah.
Those
are
like
tied
to
our
SDK
and
that's
a
I,
don't
think
like.
F
We
would
be
like
against
any
open.
Telemetries
overall
philosophy
of
API
versus
SDK
part
I
do
see
like
Azure
sdks
are
trying
to
do
that.
Approach
like
Azure
sdks
would
have
a
like,
like
instrumentation
Library,
being
same
as
instrumented
library,
because
they
natively
produce
activities
and
meters,
and
then
there
could
be
like
some
launchers
or
I.
Don't
know.
What's
the
right
word,
which
is
has
this
extension
methods
very
specific
to
the
SDK
vgp
ship?
There
is
no
obligation
that
a
user
has
to
do
that
extension
method.
F
C
F
Yeah
I
I'm,
generally
thinking
like
APA,
is
going
to
be
used
by
like
like,
for
example,
like
radius
or
or
those
libraries
I,
don't
know
whether
they
would
be
comfortable
taking
a
Microsoft
extensions
dependency
brought
to
them
by
open
Elementary
dot
API,
because
at
some
point
like
we,
we
some
libraries
definitely
need
to
access
a
propagation
and
baggage,
so
they
they
may
not
be
completely
covered
by
the
diagnostic
source.
F
So
I
I
don't
know
like
whether
they
will
be
comfortable
taking
a
like
bringing
additional
dependencies
on
the
API.
C
F
F
Check
the
ideal
world,
is
we
don't
we
stop
shipping
APA
from
our
report?
That's
the
like
Ideal
World,
because
once
baggage
specification
moves
to
stable,
then
we'll
have
another
attempted.net.
Exposing
a
tag
is
equivalent
independent
of
tracing
and
you
already
have
propagators.
We
we
just
having
like
really
documented
how
to
use
that.
But
once
that's
the
case,
then
there
is
no
reason
for
anyone
to
take
a
dependency
on
the
API
itself.
B
D
B
F
F
F
F
F
Maybe
I
won't
be
here
for
next
few
minutes,
but
I
just
want
to
see
like
one
example.
So
can
we
look
at
one
of
our
own
instrumentation
libraries,
which
only
have
a
API
dependency
like
go
to
the
stack
exchange,
reduce
client?
We
have
in
the
country,
repo.
F
So
first
open
the
cs
plus
just
to
confirm
we
have
an
API
dependency,
only
yeah
so
like
what
would
we
the
situation
like
where,
if
we
want
the
like,
we
are
our
own,
like
customer
in
this
case,
because
we
are
writing
an
instrumentation
Library.
So
if
you
were
to
follow
the
guidance
about
providing.
F
Extension
method
on
a
service
collection,
then
we'll
need
a
SDK
dependency.
So
if
you
were
to
follow
what
we
just
described
earlier
is
we
should
need
another
package
separate
from
this
package
like
open,
Elementary,
instrumentation,
stack,
exchange,
reduce
dot,
extra
extensions
or
like
launcher
right.
That
would
be
our
only
option
if
you
are
to
keep
the
stack
exchange
instrumentation
only
depending
on
API.
D
D
F
Oh
you're,
saying
like
we
should
make
this
an
SDK
dependencies
yeah.
So
that's
a
general
like
that's
the
thing
we
Challenge
and
it's
against
the
overall
fundamental
philosophy
of
open
Telemetry,
because
instrumentation
should
only
have
it
API
dependency.
So
in
this
extreme
case
one
can
support
the
SDK
with
their
own
SDK
and
things
will
just
work.
Fine.
C
Yeah
I
mean
we
could
have
a
second
package,
but
I
guess
yeah
I'm
glad
you're
kind
of
walking
through
the
seizure,
because
it's
kind
of
annoying
to
have
to
pull
two
packages.
I
wonder
if
a
lot
of
folks
might
not
even
find
the
other
redis
package
that
would
have
the
SDK
dependency
with
the
with,
like
the
help,
helper
methods
and
so
on
and.
F
Yeah,
it's
like
who
we
won't
control
it
like
whoever
is
forking
the
SDK
to
build
their
own
SDK.
Then
they'll
need
to
provide
a
new
launcher
for
that.
Sdk.
Yes,
that's
right,
but
this
is
more
like
being
adhering
with
the
philosophy.
I,
don't
I,
don't
know
if
anyone
actually
solved
an
SDK
with
something
else,
I
I
do
not
know.
If
anyone
has
done
that,
it's
it's
more
like
being
in
principle.
We
don't
want
it
to
be
tied
to
a
particular
sat
implementation.
B
I
think
there's
a
there's,
a
sort
of
balance
to
be
had
between
matching
Watts
other
libraries
do
and
making
stuff
more
idiomatic
to
c-sharpon.net,
because,
yes,
let's
not
bring
an
SDK
dependency
in,
but
that's
because
we've
made
that
split
between
what's
in
SDK
and
what's
in
API,
so
I
think
it's
more
idiomatic
to
do
stuff
against
the
service
collection
in
the
ways
that
you
know
enable
it
at
that
sort
of
level.
You
can
do
that
in
some
of
the
other
libraries
because
of
the
way
those
languages
work.
B
D
C
D
C
In
an
ideal
world
like
what
is
known
as
the
open,
Telemetry
API,
like
the
thing
that
is
declared
by
the
spec
now
that
ideally
is
effectively
going
to
be
the.net,
runtime
team
and,
like
you
know,
diagnostic
Source
in
the
future,
but
from
the
standpoint
of
you
know
us
being
opinionated
and
and
providing
tools
for
Library
authors
to
create
instrumentation
libraries
and
whatever
other
extensions.
C
Maybe
what
the
ape
like
basically
we're
talking
about
a
configuration
API
that
we
would
ship
to
to
folks
and
I.
Think
I.
Think
authors
would
appreciate
having
those
and
I
don't
know.
If
that's
something
that
you
know,
that's
a
realm
that
like
the.net
runtime
team,
whatever
you
know
Embark
into
so
it
is
kind
of
an
API
package
that
we're
talking
about
it's.
Just
not
the
open,
Telemetry
API
that
we're
talking
about
yep.
F
F
Okay
yeah
with
that
like
yeah,
it's
kind
of
smooth
and
it
kind
of
opens
the
door
for
like
keeping
API
dependency
directly.
Sorry,
the
extensions
dependency
into
the
API
makes
more
sense,
because,
if
Library
like
produce,
they
just
want
to
instrument,
they
don't
really
need
the
open
delimitary.api
or
they
need
system.diagnostic.
So
they
should
not
be
complaining
about
Tech
extra
dependencies.
D
D
C
F
Look,
you
probably
floated
this
idea
earlier
right,
like
our
plans
like
having
a
separate
package
specifically
for
configuration
and
how
the
instrumentations
and
other
components
depend
on
that
one
like
move
all
the
config
related
stuff
into
that
like
so
that
APA
remains
what
is
covered
with
respect
like
stat
span,
those
kind
of
things
and
everything
related
to
configuration
moving
to
its
own
package,
and
then
we
have
more
flexibility,
because
if
someone
wants
absolute,
the
APA
for
span
creation
meter
creation,
they
are
covered
without
any
extra
dependence.
F
If
we
want
the
additional
configuration
thing,
then
yes,
they
bring
extra
dependency.
So
if
I
were
to
just
translate
that
to
what
happens
today,
is
that
true
API
using.net
runtime?
So
we
don't
bring
any
extra
dependencies
to
any
Library
others,
so
those
Library
others
if
they
want
to
provide
this
extra
helpful
extension
method,
they
take
a
dependency
on
what
we
call
open,
Elementary
API,
but
in
practice,
is
more
like
a
launcher
or
config.
F
Api
yeah
I
think
doesn't
sound
like
that
bad,
like
once
you
work
through
this
whole
scenario,
but
how
difficult
would
be
to
move
some
of
the
stuff
into
the
API
itself
like?
Is
that
going
to
be
like
a
huge
effort,
or
is
it
just
like
very
like
straightforward,
maybe
plans
you
you
can
help
with
that
part.
D
C
Yeah,
just
talking
out
like
the
the
example
that
you
you
mentioned
her
earlier
see
Joe.
What
this
might
look
like
so
like
redis,
say
natively
decides
to
you
know,
pull
a
dependency
on
diagnostic
Source,
they
instrument
their
stuff
and
then
they,
you
know
they
read.
They
read
Mike's
new
documentation.
They're
like
oh,
you
know
we
should
add
these
extension
methods.
Okay,
now
we
need
to
take
dependency
and
open
Telemetry
API,
but.
D
C
Something
that
the
API
provides
is
like
baggage
today
that
the
runtime
doesn't
yet
so
maybe
like
a
message
like
rabbitmq
say
like
decides
to
natively
instrument
using
diagnostic
Source,
but
then
they
need
to
do
the
package,
maybe
propagation
whatever,
and
so
then
they
take
a
dependency
on
open,
Telemetry,
API
and
they're
dissatisfied
with
the
fact
that
they
have
that
transitive
dependency
to
the
DI
stuff.
C
Well,
maybe
that's
just
like
a
temporary
annoyance,
because
right,
the
baggage
stuff
will
ultimately
people
fold
it
into
the
runtime
stuff
and
then
all
like
some
later
version
of
rabbitmq
could
just
drop
the
open,
Telemetry
API
extension
dependency
altogether,
thereby
dropping
the
the
die.
The
dependency
injection
stuff.
F
Seems
correct
to
me,
because,
even
today,
there
is
propagation
already
capable
runtime
already
has
that
it
just
we
haven't
started
documenting
it,
so
baggage
would
eventually
land
I,
don't
know
when
but
like.
We
definitely
want
to
strive
to
that
world
towards
that
world,
where
everything
is
available
right
in
the
runtime
itself.
F
A
F
Package
yeah,
so
that
the
the
reason
why
some
libraries
want
to
take
a
dependency
on
APA
today
is
if
they
want
the
propagator
and
package.
So
in
that
case
it's
not
a
extra
configuration
stuff,
it's
the
core
of
the
API
itself.
They
really
need
the
baggage
and
propagation,
so
it
they
cannot
like
just
depend
on
diagnostic
Source
in
their
core
library
and
depend
on
API
or
SDK
in
their
like
bootstrap
or
thing.
F
That
would
only
work
for
things
like
it's,
like
those
libraries
which
do
not
need
to
perform
this
cross
communication
or
add
diet.
Support
like
credit
is
or
SQL
is
a
good
example
like
SQL
I
mean
by
default.
Sql
is
not
a
not
something
which
we
expect
to
propagate
its
context,
so
it
doesn't
need
propagator,
and
it
has
no
business
with
the
package
as
well.
So.
A
F
So
yeah
that's
the
example
which
I
was
trying
to
come
to
so
like
imagine,
you
are
SQL.
You
just
take
a
dependency
on
the
diagnostic
Source
alone,
so
you
don't
ever
complain
about
extra
dependencies
because
your
only
dependence
is
diagnostic
source,
and
that
has
everything
you
need.
The
span:
API
meter,
API,
propagator,
API
and
eventually
package.
F
So
you're
done
with
that,
but
for
users
to
use
it,
you
have
two
options:
one
is
you
just
publicly
announce
the
name
of
the
activity
source
and
the
meter
secure
client
is
using
so
users
can
simply
call
like
ad
source
and
add
meter
with
the
name
or
if
they
want
like
more
fancier
launcher,
then
secret
client
has
to
ship
a
separate
bootstrapper
library
and
that
Library
can
take
a
dependency
on
our
SDK
and
offer
all
these
configure
extension
methods.
A
Oh
yeah
I
thought
you
mentioned
like
not
not
the
bootstrapping
part
I
thought
like
we
would
ship
another
package
which
will
expose
the
API
config.
F
Yeah,
so
it's
like
whoever
is
building
that
instrumentation.
So
in
case
of
SQL,
we
are
the
instrumentation
Library.
We
need
to
have
a
separate
instrumentation
library,
but
the
example
which
Alan
was
asking
to
earlier
was
like
deciding
to
instrument
themselves.
There
is
no
need
of
a
separate
instrumentation
Library.
The
library
itself
you
can
serve
instrumented,
just
like,
like
Azure,
is
taking
what
they're
trying
to
do.
They
are
trying
to
like
build
APA
centimeters
directly
into
it,
so
they
are
the
instrumented
library
and
the
instrumentation
Library.
There
is
only
one.
F
A
I
think
I
still
don't
like
I,
don't
know
if
I
click
Miss,
like
I,
have
explained
my
question
correctly
but
like
what
I
was
thinking
was
that
we
could
have
a
package
like
from
the
main
Reaper,
which
offers
these
features.
And
then
any
instrumentation
Library
who
wants
to
make
use
of
this
di
stuff
can
also
take
a
dependency
on
the
package
that
we
published
I'm,
not
talking
about
per
instrumentation
Library
having
a
bootstrapper
library
or
anything
like
that.
F
Like
configuration
related
stuff,
yeah
yeah,
that's
what
like
Java
does
like
I
think
having
like
investigative
enough,
but
plans
and
Alan
did
mention
that
like
Java
does
some
and
even
python
has
something
like
that,
and
they
expect
the
instrumentation
library
of
this
to
take
a
dependency
on
that
package
to
like
offer
like
some
easy
to
use
more
user-friendly
apis.
It's
not
like
obligation,
but
it's
nice
to
have.
F
This
is
like
new
idea:
I
haven't
like
ever
spent
enough
time
like
like
working
or
how
would
that
look
like
plans
did
mention
like
such
an
idea
like
in
the
past,
maybe
Ellen
also,
but
that's
something
which
we
have
never
actively
pursued.
E
E
F
But
that's
optional,
like
if
stack
exchange
decides
to
just
have
like
symbol,
API,
not
the
fancy
configuration,
then
they
can
choose
to.
D
F
Like
yeah,
if
that's
the
case
where
like,
if
they
decide,
okay
I,
don't
want
the
dependency
injection
dependency
over
like
any
extra
dependency
into
my
library,
then
they
can
stay
as
clean
as
possible.
A
Yeah
I
think
that's
also
a
good
approach,
because
then
it
kind
of
makes
it
easier
for
someone
to
like
documents
like.
If
somebody
wants
all
of
those
features,
they
just
have
to
depend
on
API
and
then,
if
they're
very
particular
about
like
using
diagnostic
source
for
instrumentation
and
having
just
the
DI
part,
then
they
just
bring
in
that
package
and
if
they
want
I
mean
then
they
have
they
I
can
see
if
they
want
context,
propagation
and
Di.
A
E
F
F
So
I
I,
don't
think
like.
There
is
any
strong
reason
why
we
should
ship
it
in
number.
It
would
be
nice
if
you
ship
it
in
a
number,
because
now
we
can
say
we
are
like
well
aligned
with
the.net
release
cycle
like
we
ship
something
which
works
very
well
in
dot,
Net
7
as
well,
but
that's
not
like
a
very
strong
result.
F
B
F
D
F
The
minimal
thing
they
can
just
have
a
dependency
on
the
API
and
they
won't
complain
about
extra
dependencies.
If
this
is
the
like
net
summary,
then
I
think
we
have
a
good
reason
to
keep
with
that
and
not
delay
the
shipping.
E
So
what
would
we
do
for
the
future
and
repo
with
like
stack,
exchange
and
start
lettuce,
but
we
say
it's
not
going
to
support
this
stuff,
or
would
we
switch
it
to
have
that
SDK
dependency?
I
think
it
would
be
good
if
all
the
official
stuff
I
don't
know
if
contribut's
consider
it
official
but
I.
Think
all
the
stuff
under
our
purview
shouldn't
be
consistent
and
support
all
the
standard
stuff.
F
Like
they
already
support,
like
reading
configuration
from
the
I
deferred,
Tracer
Builder
right
that
would
that
not
be
considered
like
sufficient
for
most
users?
This
is
like
specifically
targeting
like
those
Library
others
who
wants
to
do
like
extra
stuff,
which
is
not
really
required
for
everyone.
F
So
if
you
modify
all
our
libraries
to
do
it,
then
it
kind
of
means
that
okay,
this
is
a
mandatory
thing,
so
maybe
like
we
can
show
it
in
like
one
library,
but
maybe
the
one
which
already
has
an
SDK
dependency
anyway,
like
HTTP
client,
but
I,
don't
think
we
need
to
go
and
modify
like
SQL
or
reduce
to
have
an
SDK
dependency.
It's
not
something
which
they
have
today.
So
we
should
not
like
do
it
just
to
demonstrate.
E
F
E
It's
the
options
essentially
so
I'm
working
on
the
doc
updates
to
show
like
how
you
bind
eye
configuration
to
options,
how
you,
how
you
do
environment
variables,
these
types
of
things,
those
need
the
service
to
learn.
You
want
to
participate
in
like
named
options
and
correctly
registering
the
delegates,
so
I
I
just
closed
some
issues
for
I
think
it
was
asp.net
core
instrumentation
Travis
sprays,
because
it
didn't
behave
consistently
in
the
options
world.
E
D
C
E
So
I
will
offline
mess
with
how
we
can
move
these
things
somewhere
in
a
future
release
either
to
API
or
some
other
active,
we'll
probably
have
to
define
a
couple
types.
But
then
we
can.
We
could
do
that
which
will
be
pretty
low
impact
in
SDK
right
now,
so
we
can
ship
it
and
then
four
one
five
or
some
future
release.
When
we
have
a
plan
we
can
move
it
and
hopefully
we'll
just
be
seamless.
E
Probably
just
means
we
split
a
couple
of
the
extension
classes,
but
that's
really
no
big
deal
for
us.
It's
two
classes
where
we
have
one
that
will
both
be
public,
but
it
will
basically
allow
us
to
move
things
independently.
So
we
just
want
to
move
these
two
operations
like
configure
Services
configured
Builder.
There's
an
attribute.
It's
like
tight
forward,
something
like
that.
It's
in
runtime,
as
long
as
we
move
it
to
a
lower
dependency.
So
it's
in
SDK
right
now.
If
you
move
it
to
API
or
if
we
move
it
to
a
future
assembly.
E
So
long
as
that
assembly
is
consumed
by
SDK
users
will
never
know
the
difference,
it
will
just
work.
Basically
at
runtime,
it'll,
Follow,
That
Type
forward
use
the
new
one
it'll
just
work
for
users.
It's
sort
of
how
runtime
is
able
to
relay
out
dependencies
and
move
things
and
do
its
thing.
We
could
use
that
same
mechanism.
F
Like
would
that
mean
like
we
won't
be
able
to
do
the
API
review
like
until
we
like
do
that
moving
around
right,
because
it
will
still
change
the
public
API
from
one
place
to
another.
But.
F
B
So
I
won't
be
around
on
Tuesday.
Unfortunately,
unless
we
want
to
do
it
an
hour
later,
which
probably
wouldn't
work
with
public
schedules
and
whatever.
F
We
should
just
proceed
at
Martin
like
you
are
like
really
strongly
aggressed
too
during
so
we
can
try
to
tweak
to
meet
your
needs
as
well,
because
we
need,
like
someone
other
than
the
maintainer,
to
give
us
opinion
from
an
external
user.
So
we
really
think
it's
useful
if
you
are
also
in
the
meeting.
B
So
I'm
unavailable
until
around
quarter
to
nine
GMT
I'm
sure
what
that
is.
F
D
F
D
C
F
Yeah,
let's
say
one
o'clock,
one
pm
to
2
P.M.
A
F
Okay,
yeah
I
think
then
we
can
click
reconvene
on
that
date
and
take
things
from
there.
But
just
enough
like
I
I
would
consider
myself
like
not
available
for
the
next
five
weeks.
F
I
might
actually
make
it
to
next
Tuesday
because
I'm
only
traveling
next
weekend,
so
but
yeah
just
an
FAA
but
don't
block
on
me
like
if
we
are
like
at
least
two
of
the
maintenance
are
available
and
someone
like
Martin
from
like
a
external
perspective,
then
we
should
proceed
okay.
F
So
when
you
like
make
the
I
think
Alan,
you
already
posted
in
the
Community
Channel
right,
the
slack
channel.
So
let's
post
it
again
for
next
week,
also
saying
that
we
are
meeting
two
hour
later
for
next
week.