►
From YouTube: 2022-08-03 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
C
A
B
All
right,
I
think
we
have.
A
B
A
Have
two
items
in
the
agenda,
but
there
are
probably
some
open
peers
which
which
might
be
to
discuss
as
well.
Let's
start
with
the
first
one
merge.net
7
branch
after
the
beta
release.
I
don't
know
whether
it's
a
question
or
do
you
know
who
added
that?
Is
it
alain
or.
D
B
A
Yeah,
so
we
will
be
doing
the
release
right
after
the
sick
meeting
today
and
once
the
release
is
done.
This
would
be
like
a
next
step.
We
will
into
main
this
is
what
we
are
asking
right.
B
B
Yeah
can
can
I
then
ask
to
have
these
open
tracing
machine
picks
before
the
release
of
the
package,
not
not
sdk
api,
but
the
the
shim
itself.
B
A
A
I
mean
the
only
reason
why
we
were
like
trying
to
keep
dot
net
seven
as
a
separate
branch
was
if
there
is
a
need
to
release
stable
version
of
prometheus.
If
the
primitive
spec
gets
stable,
then
we
wanted
to
release
it.
So
that's
why
we
decided
to
keep
dotnet
seven
brands
separately,
but
from
the
current
phase
the
prometheus
spec
is
very
unlikely
to
be
stable
in
like
next
few
weeks.
A
So
it's
going
to
be,
like
I
mean
even
if
it
gets
stable
in
like
september
or
october,
we
can
still
ask
people
to
wait
one
more
month,
so
we
don't
need
to
like
have
the
two
separate
branches.
A
So
now,
let's
see
follow
like.
Can
you
walk
us
through
this
issue
and
why
why
do
you
want
the
release
to
be
not
done
with
diagnostic
source?
Seven
oops.
Sorry,
I
didn't
get
a
chance
to
look
at
this
yet.
B
Yeah
I
can
give
a
quick
explanation
is
just
because
there
is
a
special
case
for
this
legacy
activity,
this
one
that
you
are
highlighting
and
basically
what
it
does
is
when
the
parent
is
that
it
doesn't
create
a
new
activity,
just
set
the
current
to
eat
that
one.
So
the
shin,
if
there
is
a
a
spend
being
created
by
open
tracing
that
first
spam,
doesn't
is
not
created,
but
the
original
from
asp.net
core
is
closed
when
the
one
from
open
tracing
is
closed.
B
So
that's
why
you
have
kind
of
two
bugs
old
bugs
related
to
this
stream
that
are
kind
of
bringing
the
parents
child
relation.
I
did
a
very
minimal
fix.
I
just
removed
the
special
code.
B
Perhaps
in
the
beginning,
when
this
was
created,
there
was
some
reason
for
that
to
have
this
special
case,
but
nowadays
I
can't
see
cases
that
you
wanna
to
kind
of
separate
the
trade
or
open
tracing
from
the
instrumentation
from
open
telemetry.
You
know
so
I
took
the
very
minimal
kind
of
fix
of
trying
to
just
remove
that
special
case.
A
Okay
yeah,
I
actually
didn't
realize
that
we
had
a
special
case
for
asp.net
core
okay,
okay,
so
yeah.
I
actually
got
a
little
bit
confused
in
the
beginning
because
the
shim
you
are
referring
to
is
the
open
tracing
ship,
okay,
that
makes
sense
yeah
because
we
used
to
call-
or
we
still
called
the
apa
as
a
shim
around
activity.
So
that's
not
the
one
you
are
referring
to
correct.
A
Okay,
and
so
can
you
explain,
like
you
said
you
want
this
to
be
released
as.
B
I
I
just
what
what
I
wanted
this
for
us
on
auto
instrumentation,
if
it
doesn't
need
to
be
on
these
reviews
today,
but
and
doesn't
need
to
be
officially
stable.
Yes,
but
I
want.
I
would
like
to
have
one
release
of
that
p4.net
seven,
because
when
you
switch
for
net
seven,
it's
a
whole
kind
of
things
that
you
have
to
verify
on
auto
instrumentation,
because
right
now,
for
instance,
for
dot
net
c,
there
is
no
conflict
between
the
versions
right
of
the
diagnostic
dll.
B
So
I
would
like
to
have
that
fixed,
because
I
have
some
customers
that
use
open
tracing
and
they
are
migrating
to
telemetry.
Okay.
So
I
would
like
to
have
that
fixed
before
I
have
a
release
with
not
seven.
B
Yeah,
it
doesn't
need
to
be
stable,
doesn't
need
anything
like
that,
but
we
need
some
some
really
this
week.
You
know.
A
Okay,
okay,
so
let's
see
if
we
can
do
it
like
today
itself,
if
not,
we
should
do
one
more
release
before
we
merge
the
thing
back,
because
once
you
merge
that
that
point
onwards,
we
are
on
diagnostic
source,
seven
preview,
something
okay,
yeah
yeah.
I
put
a
note
here
and
we'll
see
like
how
to
orchestrate
the
release.
Maybe
we
can
do
some
special
release
for
open
tracing,
because
this
is
anyway
not
treated
as
a
core
package,
so
it
still
follows
the
packed
patent
for
instrumentation
libraries,
okay.
A
C
A
Only
requirement
is
you
need
that
fixed
before
the
diagnostic
source,
seven
daughter
is
picked
up.
Okay,
all
right
see
if
there
is
anything
else
in
the
agenda.
If
not,
I
would
like
to
see
if
blanche,
maybe
if
you're
here,
can
you
help
us
walk
through
the
pull
breakers,
where
you're
adding
da
based
configuration?
B
B
A
Yeah,
do
you
want
to
like
just
walk
us
through
the
pr,
because
it
might
help
folks
do
a
better
review?
I've
been
like
trying
to
understand
it.
I
agree
it's
a
little
bit
more
complex
than
I
was
anticipating.
So
if
you
can
explain
little
bit
of
context,
you
can
help
more
folks.
A
If
you
want
you
can
take
over
the
sharing.
So
it
may
be
like
easier
for
you
to
control
the
screen.
A
A
Yeah
I
stopped
sharing,
so
you
should
have
permission
to
share
now.
D
D
So
this
needs
the
provider,
but
it's
hooked
in
here
sort
of
as
elegantly
as
I
could
into
you
know
like
the
service
registration
pattern.
So
you
don't
really
need
to
know
anything
about
this
like
you're,
not
passing
in
the
provider.
It
just
knows
how
to
go
and
get
it.
So
this
was
kind
of
the
main
goal.
A
D
You
have
different
options.
The
way
sirilog
asks
you
or
tells
you
to
configure
itself
is.
D
A
Yeah,
so
this
would
be
like
this
add
even
source
logo
meter
would
be
the
thing
which
is
provided
by
the
event
source
adapter
shim
extension.
Whatever
we
end
up
calling
it,
and
so
the
guidance
would
be
like
if
you're
writing
a
log
emitter,
then
you
would
provide
some
extension
method
on
the
logger
options.
Class.
B
A
Yeah,
the
usage
is
pretty
clear
to
me.
I
I
don't
know
whether
you
are
going
to
explain
the
other
part
or
you
are
going
to
explain
how
the
extension
method
internally
works.
The
add
event
source
log
emitter
internally
on.
D
So
what
I'm
doing
on
this
pr
is
really
exposing
the
same
set
of
features
we
have
for
traces
and
metrics
and
then
I'm
just
using
them
on
here,
so
this
guy
needs
access
to
the
provider.
So
what
it's
really
doing
under
the
hoods
is
it's
just
calling
this
configure
provider
and
saying
okay
once
the
final
thing
is
ready,
then
I'm
going
to
use
it
so
I'll
kind
of
show
that
real,
quick.
D
A
B
D
A
D
The
reason
we
have
this
at
all
I'll
try
to
explain
because
it's
it's
kind
of
evident
all
over
the
place
and
it
really
comes
down
to
how
the
extensions
or
the
hosting
engine
how
it
configures
and
starts
up.
The
whole
thing
is
built
on
kind
of
a
two-phase
startup
cycle.
You
have
a
phase
where
you
configure
all
your
services
and
then
you
have
a
phase
where
you
configure
your
pipeline.
D
So
what's
really
going
on,
is
you
configure
the
service
collection
and
then
in
this
build
call
you
basically
finalize
it
and
now
you
have
live
objects
and
anything
you
do
at
this
point.
The
services
are
basically
closed.
So
you'll
see
all
over
asp.net
core.
Usually
you
get
two
things
you
get
some
kind
of
ad
call
and
then
you
get
some
kind
of
use.
D
Call
all
that
really
is
under
the
hoods
is
phase
one
or
phase
two,
if
it's
an
ad
you're
just
stuffing
stuff
in
the
service
collection,
if
it's
a
use,
you're
actually
getting
the
final
things
that
are
composed
of
all
the
services
we
don't
have
add
and
use
calls.
We
just
have
an
ad,
so
we're
trying
to
do
everything
in
the
first
phase,
that's
where
it
gets
really
tricky.
D
D
D
D
This
call
right
here
is
firing
through
the
options
api.
That's
all
post
configuration,
that's
all
phase
two,
so
you
don't
have
the
ability
in
this
callback
to
add
services.
They've
already
been
closed
at
that
point,
so
there's
no
way
in
the
existing
way
to
do
that
type
of
registration
where
you
want
to
set
up
services
and
register
something.
Does
that
kind
of.
D
A
I
mean
I
am
just
letting
everyone
else
also
know.
If
you
have
questions,
please
do
erase
it
right
now.
B
C
Yeah
can
continue
so
yeah.
I've
been
having
some
thoughts
and
I
still
don't
have
a
fully
pledged
idea
but
along
the
idea
of
what
you
were
talking
about
with
using
the
service
provider
is
how
much
we
can
just
dump
in
the
service
provider
and
have
it
just
use
the
service
provider
for
everything.
C
So
do
you
provide
two
modes
or
not
so
yeah?
I'm.
I
want
to
have
a
look
at
the
pr,
because
I've
still
not
had
a
chance
to
have
a
look.
I
don't
know
whether
he
did
send
a
link,
but
I
think
there's
some
some
stuff.
I
would
like
to
see
around
just
being
able
to
add
a
load
of
the
exporters
more
specifically
and
just
have
it
pick
them
all
up
as
the
default
mechanism,
rather
than
providing
a
callback
to
do
it
to
just
say,
go
and
find
them.
C
D
So
I
did
add
this
scenario,
which
is
more
for
that
case,
where
you
just
want
to
load
up
some
processor.
I
didn't
do
exporter
because
you
kind
of
need
a
processor
tied
to
the
exporter.
I
don't
know
what
it
would
do
like.
If
it
just
found
an
exporter,
then
it
would
kind
of
have
to
guess
is:
should
this
be
a
batch
or
a
simple
processor?
So
I
I
just
did
processor.
D
We
could
talk
through
the
exporter
case,
but
I
basically
did
this
for
you,
martin,
based
on
what
you
were
asking
for
on
slack,
which
is
the
ability
just
to
dump
any
random
processor
into
the
service
collection,
and
then
it
will
pick
it
up
automatically.
C
Yeah,
I
think
we
will
need
to
disable
on
that,
though.
If
we're
gonna
say
that
we
will
probably
want
to
be
able
to
say.
Can
I
inside
of
the
ad
open,
telemetry
options
there
say:
do
use
the
service
collection
or
don't
use
it,
because
that
might
have
some
undesirable
effects
for
some
people.
I
think
it'd
be
fine
to
have
a
default
on
or
if
somebody's
added,
maybe
they've
got
two
open
telemetry
providers
that
they're
doing,
which
is
a
I've,
seen
a
ticket
around
being
able
to
register
two
hotel
providers.
C
Maybe
one
of
them
wants
to
use
the
dependency
injection,
whereas
the
other
one
doesn't.
Maybe
so
we'd
probably
want
something
that
says:
yes,
use
it
or
don't,
but
yeah.
My
specific
thing
was
exporters,
the
use
case
being
I
want
to
add
an
in-memory
exporter
for
when
I
use
a
use
it
as
part
of
an
integration
test
or
part
of
the
web
app
factory.
D
D
A
B
Your
pr
michael.
B
D
D
B
C
A
Yeah,
so
the
one
which
you
are
referring
to
is
for
not
for
logging,
like
we
were
earlier
debating
about
what
about
tracer
provider
and
meter
provider
like
do
we
allow
users
to
add
it
like
more
than
once,
what
is
expected
behavior
so
so
that's
the
one
which
you
are
referring
to
the
unit
test
is
just
validating
that
we
have
assembly
where
you
can
have
multiple.
D
A
So
if
the
behavior
is
I
I
was
asking
if
the
behavior
is
decided
to
be
like,
we
only
allow
the
provider
to
be
registered
once
then
it
would
make
sense
to
bring
the
same
two
traces
as
well
right,
because
then
we
know
there
is
only
one
provider
to
attach
the
processor
or
assembler
to.
D
D
You
from
doing
it
it's
just
what
we
want
to
kind
of
support
out
of
the
box.
So
if
I
build
the
provider
here
build
provider,
I
can
create
a
fully
disconnected
second
instance
and
still
safely
use
all
the
extension
methods,
because
they're
all
building
a
separate
instance.
You
know
service
collection,
if
that
makes
sense.
A
So
that's
like
it
was
not
really
part
of
this
pr,
but
I
think,
like
there
is
general
agreement
that
we
only
need
to
support
the
single
provider
use
case,
but
we
are
not
doing
anything
explicitly
to
prevent
users
from
spinning
them
as
many
as
they
want.
C
C
So
it's
not
per
app.
If
you
want
to
create
two
service
collections
and
do
that,
then
you
know
your
prerogative
but
we're
on
this
point
once
per
service
collection,
exactly.
A
D
C
Traces,
the
same
use
case,
though
sorry
could,
you
repeat
traces,
I
think,
has
probably
even
more
of
a
use
case.
You
know
if
you've
got
certain
types
of
certain
sources,
tying
the
sources
to
different
to
different
telemetry
back
ends,
I
think,
would
be
lots
of
different
exporters,
maybe
even
with
different
processors.
A
A
Within
our
company
for
logging,
because
they
use
a
separate
pipeline
for
special
type
of
logs,
it's
independent
of
the
regular
pipeline.
I
have
seen
that
use
case
in
practice
for
logging.
I
have
also
seen
it
for
the
matrix
and
traces
as
well
like
just
like
what
you
just
described
like
for
certain
activities,
sources
and
certain
meters.
C
A
A
Yeah,
it
is
valid
use
case.
Spec
explicitly
asks
every
sick
to
support
it.
You
can
have
any
number
of
providers
each
with
its
own
configuration
and
we
do
support
it.
So
this
this
da
based
thing
is
the
only
one
where
we
respect
like.
If
you
have
a
single
container,
we'll
have
a
single
provider.
If
you
want
10
providers,
then
you
spin
up
10
like
set
10
da
container.
A
C
I
think
so
yeah,
I
think
it's
the
like
we're
saying
for
logging,
stuff
you'd
want
to
potentially
say
well
info
login
is
going
to
go
to
a
rapid
store,
whereas
debug
logging
is
going
to
go
to
a
a
cold
store,
they
might
have
different
places
that
they
go.
One
logging
error
logging
might
go
to
reagan,
for
instance
versus
info
logging
going
into
a
different
pipeline.
I
think
those
two
are
probably
really
valid:
use
cases
for
a
single
service
collection.
C
No,
so
your
info
logging
wouldn't
go
to
the
same
as
your
error.
Login
and
your
error.
Logging
wouldn't
potentially
go
to
the
same
as
your
info
login.
A
Okay,
when
you
say
pipeline
like
here,
are
you
referring
to
the
open
elementary
paper
plan
because
open
elementary
is
one
provider
and
within
open
telemetry?
We
have
like
any
number
of
exporters,
so
yeah,
so.
C
It's
meaning
that
the
the
exporter
you'd
have
to
do
a
lot
in
the
export
configuration
other
than
if
you
were
to
do
it
as
one.
What
I
would
consider
a
pipeline
is
adding
the
processors
adding
any
set
resource
builder,
all
that
kind
of
stuff
and
a
series
of
exporters
off
the
back
of
it.
That,
together,
I
would
say,
is
a
pipeline
inside
of
what
we're
doing.
A
So
what
is
a
like,
like
like
blanche,
it's
for
you
like
in
the
current
pr
like
we
are
explicitly
only
allowing
a
single
provider
like
no
matter
how
many
times
you
call
it.
It's
still
going
to
act
upon
the
same
provider,
and
if
you
had
like
10
processors,
it's
all
going
to
get
attached
to
the
same
provider
right!
That's
how
it's
currently
designed.
B
A
Okay,
yeah
and
it
it's
definitely
possible
like
for
users
to
like
still
like,
add
and
spin
up
more,
but
I
am
trying
to
see
like
how.
How
would
it
look
like
based
on
the
scenario
which
martin
was
just
describing?
You
still
have
a
single
service
collection
and
how
do
you
like
add
multiple
providers
or
multiple
pipeline,
I'm
still
not
sure
like?
How
would
we
achieve
that
here.
C
C
Sure
we're
not
missing,
so
we
can
also
drop
them
in
the
documentation
afterwards
as
well.
Well,
there's
the
different
things
that
we've
considered,
and
this
is
how
you
would
achieve
them.
A
If
you
have
left
for
place
assigned
matrix
also,
please
do
that
because
we
did
discuss
this
in
the
like
past
as
well.
Without
anything,
we
didn't
really
conclude
anything.
We
were
mostly
assuming
that
one
provider
is
sufficient,
but
there
are
like
more
cases
which
we
are
not
aware.
It
would
be
helpful
at
these
two.
If
you
can
leave
a
comment,
we
can
consolidate
them
into
a
final
place.
C
Yeah,
the
the
metrics
one
I'll
struggle
with
metric
is
in
my
strong
suit.
Logging
and
tracing
is
definitely
my
wheelhouse
sport
I'll
see
what
I
can
do.
D
D
D
You
can't
do
this
today
on
the
other,
sdk
crate
providers,
they're
really
kind
of
net
framework
focused,
but
if,
in
the
logging
world
now
on
this
pr,
if
you
author,
an
extension
like
the
one
that
I'm
adding
on
here-
that
I
showed
earlier
this
guy,
so
this
extension
is
using
the
service
collection.
It's
using
configure
provider,
it's
using
options,
it's
using
all
the
corey
extension
library
stuff,
but
the
same
exact
methods
will
also
work
on
dot
net
framework,
because
what
I
did
is
this
builder
that
we're
creating
here.
D
Is
basically
wrapping
its
own
instance
of
all
that
stuff,
so
it
is
kind
of
under
the
scenes
making
sure
that
okay,
it
has
a
service
collection
in
phase
one
you
can
add
to
it.
Then
it's
gonna
build
it.
Then
it's
gonna
invoke
all
the
callbacks.
It's
gonna
invoke
all
the
options
it's
gonna
hook
it
up,
just
like
you
were
doing
it
through
the
typical
extension
that
you
would
on
the
host
service
collection.
So
it
just
kind
of
takes
care
of
all
that.
D
To
give
you
basically
the
same
api,
but
completely
detached
from
the
host's
global
service
collection.
So
there's
a
lot
of
value
in
this.
In
that
now
you
can
create
multiple
providers,
but
you
get
all
the
same
extensions,
the
same
api
service,
all
the
great
goodness
just
in
its
own
detached
isolated
version.
C
In
that
scenario,
how
would
you
attach
that
to
the
logging,
so
you
just
created
a
second
one
there.
How
would
you
now
attach
that
to
the
the
inbuilt
logging
in.net
so
whenever
I
create
an
I
logger
and
do
log?
How
do
I
connect
those
two
together.
D
So
you
have
a
couple
options:
this
provider,
you
don't
necessarily
need
to
use
through
any
kind
of
blogging
framework.
So
if
you
were
building
like
you
know
a
log
emitter,
I
don't
know
if
I
can
get
it
there,
it's
all
internal
right
now,
so
I
can't
hit
that
api.
If
you
needed
to
get
a
provider
to
plug
into
like
siri
log
or
log
for
net,
you
could
do
it
this
way.
You
could
also
just
create
a
logger
from
this
guy.
You
don't
necessarily
need
to
hook
into
a
logger
factory.
D
C
Right,
okay,
I
suppose
that's
the
the
line,
99,
that's
what
I
was
more
meaning,
because
what
I'd
be
looking
for
as
a
developer
is
I
don't
want
to
be
switching
out
which
logging
factory
I'm
using?
I
want
my
code
that
I'm
already
using
injecting
and
I
logger
into
into
those
classes.
I
want
that
to
go
through
both
of
the
two
providers,
where
one
of
them
sending
it
to
one
place
and
one
of
them
sending
it
to
another.
One
of
them
has
some
pre-processing.
One
of
them
has
no
pre-processing
all
of
that
kind
of
stuff.
D
D
B
C
I
suppose
the
big
use
case
for
me
is
just
talking
just
literally
just
talking
to
somebody
today
about
their
usage
of
ray
gun,
as
an
error
provider
is
being
able
to
use
open
telemetry
as
a
filter
that
has
a
output
that
goes
into
raygun,
but
is
literally
only
for
error
monitoring.
So
I
want
to
be
able
to
just
configure
it
so
that
it
only
listens
to
logs
of
type
error.
A
D
D
C
Yeah,
I
suppose
I'd
be
expecting
them
to
be
both
otlp
exporters,
because
I'd
be
expecting
raygun
and
you
know
whoever
else
I'm
using
for
analogs
io
as
the
two
places
I'm
going
to
send
my
logs.
C
I
think
the
just
add
my
exporter
in
there
would
be
better
because
I
would
be
having
to
create
something
new
but
yeah.
I
suppose
the.
C
Was
it
it
isn't
particularly
bad
to
do
it
that
way,
just
asking
the
providers
when
they
create
their
wrapper
around
otlp
exporter
is
that
they
need
to
do
the
filtering
inside
of
their
stuff
or
provide
them
with
options
to
do
it.
D
C
D
C
Yeah
but
yeah
as
long
as
we've
got
an
answer
of
how
we
do
it
and
it's
relatively
simple
for
people
because
creating
the
approach
that
you've
got
there
I
think,
does
fly
in
the
face
of
a
lot
of
what
me
as
somebody
who
writes
dot
net
code.
I
wouldn't
be
expecting
to
do
that.
I'd
want
to
be.
Oh,
I'm
doing
something
a
bit
weird.
If
I've
got
to
create
two
providers
in
that
way,
it
would
just
feel
a
bit
weird
to
do
it.
So
if
we
do
it
by
filtering
processors,
then
great.
C
But
yeah
I
also
want
to
get
in
the
service
provider
based
exporters.
So
maybe
this
conversation
we
can
have
about
what
the
challenges
are
with
that.
D
Yeah,
what
I'd
like
to
do
if
this
pr
goes
in
some
of
what
we
have
in
the
hosting
library
is
really
just.
D
D
A
D
So
what
I
did
for
the
open,
telemetry
logger
options,
sdk,
where
it
basically
wraps
its
own
service
collection
and
stitches
everything
up.
We
can
do
the
same
for
traces
and
metrics,
so
you
get
all
of
those
same
features.
You
don't
need
necessarily
the
hosting
library
all
the
hosting
library
will
have
is
basically,
this
hosted
service,
which
just
starts
things
up
when
the
application
starts.
D
D
D
C
D
But
if
we,
if
we
leave
the
hosting
here-
and
we
pull
everything
else
in,
it
still
gives
us
a
lot
better.
I
think
more
consistent
world
for
doing
it
through
the
services
doing
it
through
the
sdk,
create
methods,
and
it
allows
us
to
kind
of
obsolete.
Like
the
the
I
deferred
stuff,
we
wouldn't
need
those
anymore,
because
basically,
every
provider
builder
would
have
all
those
features
just
baked
in
so
you
wouldn't.
D
We
wouldn't
need
this
type,
checking
that
we
do
in
these
weird
cases
where
you
could
get
into
a
situation
where
you're
using
apis
at
a
runtime
just
perform
no
ops
because
you're
not
using
hosting
so
we
could
definitely
smooth
it
out.
I
think
make
it
a
lot
better,
improve
it
from
what
it
is
and
still
keep
some
of
this.
It's.
B
C
100
agree
that,
if
we're
pulling
in
the
service
collection,
I
think
it
even
is
quite
in
keeping
with
the
the
way
that
the
pcl's
moving
anyway,
where
things
like
http
client
factory,
you
can't
do
without
a
service
collection.
You
know
everything
is
well.
If
you
want
this
thing,
fire
up
a
service
collection,
add
it
through
the
service
collection
and
do
it
that
way.
So
I
think
it's
pretty
in
keeping
with
the
way
that
a
lot
of
the
libraries
are
going.
D
This
call
right
here,
logger
factory,
create,
is
basically
doing
the
exact
same
thing.
It
spins
up
its
own
service
collection
adds
everything
to
it.
Builds
the
service
provider,
takes
the
logger
factory
out
and
returns
it,
and
then
it
wraps
the
service
provider
in
the
logger
factory
that
you
get
back
so
that
when
you
dispose
it,
it
also
disposes
the
provider
and
any
services
that
were
injected.
D
C
C
I
think
that's
completely
viable
as
a
as
a
move
forward,
because
it's
not
going
to
break
anybody's
implementations
at
all.
Really
it
just
means
that
there's
more
stuff
in
the
sdk
than
there
is
in
the
hosting
library.
D
Yep
and
what
it
enables
is
you
can
author
extensions
that
will
work
for
donna
framework
and
dominic,
like
you
can
build
extensions
on
the
service
collection
that
today,
if
you
were
doing
sdk
dot
create
tracer
provider.
None
of
those
extensions
are
available
to
you
because
it's
disconnected
from
that
whole
world.
So,
if
you
were
shipping
like
an
hotel,
adapter
or
some
kind
of
library,
some
extensions,
if
you
want
to
support.net
framework,
you
basically
need
two
complete
apis
by
bringing
that
all
into
sdk.
D
C
What
I
think
will
be
amazingly
cool
is
if
we
can
get
it
so
that
all
of
those
processors,
all
of
those
exporters,
literally
everything,
can
come
from
the
service
provider.
So
the
amount
of
setup
to
do
in
adding
open,
telemetry
tracing
is
actually
pretty
small
you're,
just
basically
telling
it
what
sources
to
listen
to
even
getting,
for
instance,
the
the
resource
builder
from
the
service
collection,
so
that
you
can
share
it
between
the
two
well
between
the
three.
So
it's
using
the
same
resource
builder
for
each
of
them.
A
C
D
C
D
C
No,
I
was
what
I
was
meaning
is
builder.services.ad
singleton
of
type
the
well.
What's
the
ot
otlp
exporter,
so
otlp
exporter
with
the
configuration
in
the
services
so.
D
You
can,
as
of
this
pr.
D
D
A
A
So
just
a
simple
export,
simple
processor,
just
give
it
some
name
like
my
custom,
processor
or
something.
A
D
D
A
I
think
that's
the
like
general
thinking,
which
I
I
had
because
I
have
previously
done
this
in
application
sites
where
people
all
they
do
is
like
service
a
stored
ad
application
inside.
So
similarly,
I
was
anticipating
like
something
like
services,
stored,
add
open,
telemetry
and
everything
else.
C
Yeah,
I
think
you
know
I
was
working
on
something
recently
in
the
there
was
like
four
different
exporters
that
they
were
using
seven
different
ad
sources,
and
I
think
there
was
like
four
or
five
different
custom
processors
that
was
for
tracing,
and
I
think
adding
all
of
those
just
to
the
di
container
would
have
really
cleaned
up
the
difference
between
what
they
were
trying
to
do.
C
With
the
the
exporters
like
they
were
trying
to
bring
in
configuration
into
the
exporters
that
they're
having
to
pull
out
the
configuration
from
app
settings
using
builder.configuration.
First,
just
adding
those
to
the
di
containers
would
have
really
cleaned
up
that
bit
of
code.
A
So
we
are
about
like
out
of
time,
so
what
I
propose
to
do
is
we
are
just
starting
our
next
beta
cycle.
So
this
is
the
right
opportunity
for
us
to
like
experiment
things,
because
we
have
at
least
two
three
months
before
we
go
stable.
So
we'll
go
like
really
easy
on
probably
kpa,
because
we
have
the
opportunity
to
change
it.
Since
we
are
like
just
starting
with
beta
and
then
based
on
the
feedback,
we
can
tweak
things,
bring
things
down
and
eventually
ship
the
stable.
C
So,
just
before
we
break
up,
then
the
the
hosting
stuff
trying
to
get
a
stable
hosting
one
out
before
we
try
and
redo
all
of
the
refactoring.
Are
we
still
on
that
there's
an
idea
that
we
could
get
something
out
in
the
next
month
or
so
of
a
stable
version
of
the
hosting
package.
A
D
A
Like
doing
that
route,
then
we
of
course
we
it
will
delay
the
overall
thing,
because
we
know
how
to
wait
for
the
base
sdk
to
be
stable,
which
is
going
to
be
around
november,
definitely
not
next
month.
A
But
if
you
decide
to
okay
keep
things
the
way
it
is
currently,
then
we
should
be
able
to
like
make
faster
progress
towards
the
extension
start
hosting.
But
I
I
don't
really
have
an
opinion
right
now,
because
I'm
here
to
like
really
digest
through
all
the
things
which
we
just
discussed
so
I'll
need
to
take
it
like
sing
that
idea
for
a
day
or
two
and
then
come
back
with
more
concrete
opinions.
A
Yeah,
thank
you
yeah.
So
one
thing
is
like
we
will
just
like
collect
relatively
easy
on
the
public
api
because,
like
usually,
we
want
to
keep
things
very
trimmed
down.
But
since
we
are
at
the
beginning
of
a
beta
cycle,
we
can
like
go
a
little
bit
more
relaxed
with
the
full
understanding
that
we
will
trim
off
things
which
we
don't
really
think
necessary
when
we
are
about
to
do
staple.
A
So,
okay,
yeah
thanks
blanche
for
like
detailed
presentation
and
maybe
we'll
need
like
more
in
the
next
week,
also
depending
on
how
things
shape
up
in
the
next
few
days.
A
D
C
I'd
recommend
steve
gordon's,
deep
dive
on
configuration,
yeah,
okay,.
A
Yeah,
I
I
was
about
to
recommend
the
same
thing,
that's
something
which
I
found
extremely
useful.
Maybe
if
you
can
put
a
note
on
the
I
mean
in
the
slack
channel
with
that
links,
if
any
specific
dog
stands
out,
that
would
be
great.
A
All
right,
I
think
we
are
slightly
above
time.
Thank
you,
everyone,
so
I'll
work
with
utkash
to
proceed
with
the
release
today.
I'll
see,
if
I
can
like
merge
this
pr
before
that,
but
worst
case,
we
will
not
merge
it.
We'll
still
do
the
release.