►
From YouTube: 2021-04-28 meeting
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).
A
A
A
A
Okay,
while
we
are
waiting
to
start,
I
think
we
can
start
now.
Let
me
share
something
which
is
only
applicable
for
maintenance
given
like
michael
and
eleni
here,
so
sergey
asked
all
maintenance
to
join
in
cncf.
This
name
is
something
like
dotnet
maintenance,
something
I'm
pretty
sure
like
none
of
us
have
joined.
So
please
share
your
email,
just
type
it
in
the
meeting
notes.
A
A
Okay,
yeah:
let's
go
over
the
topic
one
by
one,
it's
very
small,
so
this
is
follow.
From
last
week
like
we
were
trying
to
get
dotnet
team
to
make
an
official
recommendation
for
the
multi-targeting
issue,
like
dotnet
standard
versus
dotnet
framework
is
having
different
public
api
utkar,
and
I
reached
out
to
some
folks
from
dot
net.
We
haven't
got
the
response
rate
so
we'll
give
it
like
another
week
before
we
like
try
to
poke
more
folks
the
update.
A
So
this
was
another
update
which
I
was
trying
to
do
like
last
week
to
do
a
release
of
all
the
components
in
contrary
because
in
the
last
one
one
and
a
half
month,
we
unblocked
all
the
instrumentations
in
contribute.
However,
there
was
no
like
release
done,
so
I
had
some
issues
and
one
of
the
issue
was
some,
I
get
token
and
that's
what
forced
me
to
work
with
sergey
to
get
the
permissions
ready.
A
So
now
I
have
the
permission.
So
I
just
finished.
Like
five
minutes
back,
I
published
elastic
search
instrumentation
after
a
long
time.
So,
okay,
this
should
be
done
now,
so
I'll
follow
the
same
process
and
try
to
update
the
remaining
instrumentations
as
well.
A
Okay,
yeah
the
that's
the
biggest
update
and
let's
yeah.
This
is
another
thing
which
I
wanted
to
just
like:
give
a
it's
up
to
others,
because
this
is
a
spec
pr
which
is
adding
the
equivalent
of
suppress
instrumentation.
So
it's
something
which
dot
net
already
did
and
probably
other
languages
like
python.
A
So
now
the
spec
is
already
like
getting
ready
for
apr,
which
says,
suppress
instrumentation,
and
this
might
be
like
something
which
we
can
implement.
I
mean
we
already
have
it
it's
just
that
there
are
some
issues
with
that
which
I
have
mentioned
here.
A
But
now,
like
once,
the
spec
makes
it
part
of
the
official
spec
we
can
move.
The
suppression
feature
into
the
api
package
itself,
so
all
the
instrumentations
can
leverage
it.
So
we
just
need
to
wait
for
the
spec
to
be
merged,
so
it's
just
a
heads
up.
That
would
probably
be
the
last
the
reason
why
some
of
the
instrumentations
require
a
sdk
dependency
as
opposed
to
api
dependency.
A
Thing
like
I
asked
like
good
customer
look
at
it
as
well
like
last
week.
There
might
be
like
few
other
things
which
is
like
easily
fixable,
so
we
should
be
able
to
modify
our
instrumentations
to
purely
depend
on
the
api.
That's
like
a
it's
not
like
a
hard
requirement,
but
that's
the
like.
By
by
design
the
instrumentations
are
supposed
to
depend
on
only
the
api,
not
a
particular
sdk
implementation.
A
So
that
ends
my
topics
it's
more
like
updates.
So
let's
look
at
the
issue
which
allen
has
raised.
C
A
C
Little
bit
of
back
and
forth
on
with
austin
on
a
couple
of
his
pr's,
and
then
I
realized
that
there
was
some
other
issues
that
he
had
already
opened,
that
I
think
kind
of
touched
on
some
components
that
I
highlighted
this
issue,
but
I
just
wanted
to
make
sure
I
was
up
to
speed
with
some
of
the
other
conversations
that
were
going
on
in
case.
You
know
I'm
I'm
being
redundant
here
or
or
whatever,
but
in
a
nutshell,
I'm
posing
the
question
of
you
know.
C
Given
that
the
net
activity
api
enables
us
to
set,
you
know
arbitrary
values
for
attributes
and
then
there's
this
conversation
around
this
well,
the
specification
only
requires
you
know,
longs
and
and
doubles
effectively
and
strings
and
booleans
I'm
proposing
that
we
just
embrace
the
fact
that
we,
the
activity
api,
allows
for
an
arbitrary
type
and,
at
the
very
minimum,
just
support
all
of
the
built-in
types
in
a
in
a
way
that
seems
reasonable.
A
Okay
yeah,
this
part,
I
believe
you
had
a.
A
Comment,
I
mean
I
I
don't
have
any
objections
with
this
part
like
this
is
like
fairly
like
straightforward
api
allows.
A
I
mean
if
someone
provides
any
of
the
built-in
things
we
promote
them
to
one
of
the
spec
recommended
one
and
it's
straightforward
for
byte,
integer,
unsigned,
etc,
but
what
was
yeah
okay?
This
is
about
what
do
we
do
for
like
random
thing
which
which
we
cannot
convert
to
like
one
of
them?
And
are
you
saying
that
we
should
do
like
dot
string
or.
A
There
should
be
more
difference
here,
yeah
yeah,
I
think
my
my
suggestion
is
like,
let's
don't
do
anything
like
calling
dot
to
string
on
a
random
object,
which
we
have
no
idea
of
right,
but
continue
to
do
like
what
we
are
doing
and
like
expand
to
like
all
built-in
types.
So
would
that
be
like
acceptable
or
what
was
that?
What
you
were
already
proposing-
or
I
didn't
finish
reading
this
so.
C
C
F
Yeah
I
was
wondering
about
resource
specifically
because
in
every
case
it
should
be
treated
the
exact
same
as
the
tags
right
for
natural.
I
was
wondering
if
we
should
centralize
that.
A
Yeah,
but
for
the
difference
between
the
resource
and
activity
tag
is
the
entire
code
for
resources
in
this
repo
right
for
activity.
It's
like
elsewhere,
like
in
the
dot
net
context
yeah.
So
for
the
because
of
that,
like
for
activity,
it
makes
sense
only
to
be
doing
that
in
the
exporters
but
for
resource.
I
think,
like
we
are
already
doing
the
right
thing
like
we
are
blocking
the
construction
of
the
resource
if
it
doesn't
fit
like
one
of
the
supporter
type,
it's
oh
no!
No!
It
should
be
here.
A
And
we
check
if
it
is
like
one
of
the
supported
one.
If
it
is
neither
of
the
supported
ones,
then
we
throw
an
error,
but
for
for
activities
case,
there
is
no
like
opportunity
to
validate
it,
because
activity
dot
set
tag
does
not
throw
any
error,
so
we
cannot
throw
in
the
exporter.
So
all
we
can
do
is
like
gracefully,
ignore
it
and
move
on.
A
That's
what
I
think.
That's
what
like
allen
is
also
proposing
right,
like
in
the
exporter,
also
make
sure
we
support
all
the
built-in
types
and
if
it
is
falling
into
like
something
which
we
don't
support,
don't
throw
but
like
ignore
it
and
move
on
to
the
next
tax.
C
C
C
This
is
the
set
that
I'm
talking
about,
like,
I
think
all
of
these
types,
at
least
the
value
types
above
and
building
relatives.
Okay,
all
these
things:
okay,
okay,
right
and-
and
some
of
them
like
an
unsigned
long,
won't
fit
in
obviously
inside
of
a
thing,
so
it
might
get
truncated.
So
there
might
be
a
couple
types
here
where
we
may
just
have
to
to
string
it.
C
How
does
exporters
do
today
if
it
gets
a
value?
It
doesn't
support
it'll,
just
to
string
it
and
if
it's
an
array,
it'll
it'll
actually
be
the
type
name
like
system
dot.
You
know
you
long
array,
so
that's
not
great
and
the
reason
why
I
think
that
it
would
be
valuable
to
not
to
string
something.
That's
otherwise.
A
numeric
type
is
that
back
ends
like
new
relic,
for
instance,
enables
you
to
do
like
relational
operators
and
query
your
your
events
and
if
they're
strings,
you
can't
do
that.
C
A
Okay,
yeah
I
mean
so
you're.
I
mean
I'm
not
opposed
to
anything
here
and
you
still
agree
about
the
object
or
to
stink,
but
we
should
not
do
that
right.
A
Correct
okay,
so
basically
we
should
like
handle
that
here
like
if
it
is
not
following
the
built-in
types,
then
we
should
just
ignore
that
tag
and
continue
with
the
rest
of
the
activity.
Okay,
we're.
A
Or
logging,
something
to
so,
we
can
load
something
but
make
sure
we
don't
lose
that
whole
activity
just
right
when
tag
is
closed
and
there
is
no
option
for
throwing
exception
like
by
design
like
we
are
not
allowed
to
throw
exception
any
place
other
than
like
startup.
So,
even
if
even
if
the
entire
activity
is
like
really
bad,
we
should
not
throw
it
down.
We
can
just
catch
it
and
look
it.
A
That's
that's
like
the
general
exception
principle
from
open
door
matrix,
but
we
can
afford
to
throw
in
the
startup
I
mean
when
the
provider
is
being
built,
which
is
why,
like
it's
okay,
to
throw
in
the
resource
case,
if
you
create
a
provider
with
an
invalid
resource,
then
we
can
yeah
it's
before,
but.
E
A
Once
we
create
the
provider
like
the
system
is
like
append
running
then,
after
that
we
should
not
be
throwing
any
exceptions,
even
if,
like
some
really
bad
values
are
passed,
you
should
just
catch
it
load
it
and
move
on.
I
think
this
is
not
like
it's
a
requirement
from
upper
telemetry
itself.
It
says
like
once
the
system
starts
up.
We
should
not
punish
the
users
in
the
steady
state.
A
Alan
for
bringing
it
up
like
like
austria,
I
guess
like
you,
you
would
be
working
on
this
yeah.
I
can
connect.
F
With
download
offline
yeah,
but
I
guess
I'll
ask
one
more
thing
before
we
move
on
to
this
one.
I
hope
this
one
takes
you
along.
Is
this
proposing
any
sort
of
like
way
of
handling
this?
F
I'm
just
wondering
if,
because
like
right
now
for
each
explorer
we're
having
this
gigantic
list
of
things
and
they're
not
centralized
in
any
way,
I
feel
like
very
easily
we
miss
stuff
like
even
now
before
I
made
all
these
changes,
and
I
think
still
there
are
some
exporters
that
are
missing
it
like
some
will
support
in
some.
Don't
some
didn't
support
long
some
did
and
I'm
just
wondering
if
we,
if
it's
feasible,
to
make
something
a
little
bit
more,
centralized
that
the
exporters
pull
from.
Does
that
make
sense.
A
D
D
C
You
might
want
to
pull
in
a
few
more
actually
yeah
yeah
good
point.
It
might
actually
make
sense
to
consider
the
list
of
types
that
that
implement.
I
convertible,
which
is
date
time,
I
think,
is
one
of
those
types.
D
E
D
C
D
A
So
what
like
this
list,
like
even
in
this
list,
we
do
have
like,
like
you
already
mentioned,
like
yulong,
the
only
thing
you
can
do
is
like
call
to
string
on
it
right.
There
is
no
way
you
can
convert
that
into
like
long
or
anything
without
the
risk
of
overflow.
D
Yeah
truncation,
or
something
like
that,
I
mean
you
could
yeah
yeah
json
api,
so
it
has
like
attributes
and
it
has
an
options
object
where
people
can
like.
You
know,
extend
the
types
it
might
be
kind
of
cool
if
we
had
some
something
like
that.
So
if
people
wanted
to
write
some
complex
type
on
their
spans,
we
give
them
a
way
to
basically
serialize
it
to
whatever
exporter.
A
Yeah
I
mean
that
that
would
be
like
a
useful
thing,
even
in
the
logging
world.
We
might
like
benefit
from
that,
like
basically
putting
arbitrary
things,
and
we
want
to
like
serialize
it
using
some
way,
but
it's
probably
not
in
the
scope
of
like
this
particular
issue
like
where
there
is
a
well
defense
spec,
which
says
what
are
the
things
supported.
So
maybe
we
can
just
do
like
what
is
absolute
minimum,
which
is
to
support
like
the
ones
which
can
be
converted
nicely
and
and
the
ones
which
we
cannot
like,
like.
A
Don't
throw
don't
call
too
strong
either
and
deal
with
that,
but,
like
it's
going
like
we,
if
you
want
to
like
let
user
write
like
arbitrary
thing,
and
we
want
to
like
convert
that
that
that
should
be
like
a
separate
issue.
Right,
I
mean
something
which
can
be
leveraged
even
in
the
logger
world
like
in
I
logger
you
have
like,
I
logger
dot
log
like
any
random
object
and
we
have
like
the
exporter
or
the
processor
has
no
way
of
knowing
what
that
is.
A
D
A
The
team
about
it
a
few
months
back,
I
mean
I'm
hoping
that
there
will
be
some
resolution
from
dotnet
team,
but
it's
very
unlikely
to
happen
this
year,
because
we
believe
they
are
like
really
busy
with
matrix.
They
won't
have
time
to
really
look
at
like
logging
issues
unless
we
really
push
for
them,
but
I
mean
from
my
team.
A
I
don't
think
we
are
pushing
that
hard,
so
it
looks
like
we'll
get
metrics,
but
not
the
logging
improvements,
so
that,
like
question
of
like
how
to
serialize
like
random,
arbitrary
things,
you
pass
into
logger.log,
it's
still
undersold.
A
A
A
F
A
And
in
console,
I
think
it's
probably
fine
to
call
two
string
but
like
if
we
can
like
make
it
similar
to
one
of
the
others
that
that
would
be
cool.
But
it's
not.
F
A
I
have
like
one
small
update,
which
is
about
matrix
so,
like
I
discussed
this
with
victor
and
he's
already
doing
prototyping
with
the
dotnet
team,
so
they
have
a
fairly
good
api,
which
is
in
compliance
with
the
currently
proposed
matrix
api
in
the
spec.
So
they
are
working
like
very
closely
with
the
spec
team
to
get
the
api
out.
A
So
I
would
start
doing
like
the
first
thing
which
I
do
is
like
we'll
try
to
nuke
all
the
existing
metrics
code,
because
after
reviewing
the
existing
metrics
ap,
I
don't
think
there
is
anything
which
we
can
reuse
as
such.
So
we
just
nuke
this
folder
like
the
matrix
folder
in
api
and
sdk
and
replace
it
with
the
new
one.
So
it
should
be
like
it's
like
really
different.
Like
anyone
who's
been
following,
the
spec,
a
lot
of
things
were
removed,
there
is
no
label
said
there
is
no
bound
instrument.
A
All
those
notions
are
gone
so
to
like,
rather
than
trying
to
like
tweak
each
and
every
line
here.
We
just
look
it
and
start
over,
and
that
should
happen
like
sometime
next
week
and
to
start
we
will
incorporate
into
the
api
like
things
which
would
eventually
be
part
of
the
that.net.
So
we
don't
know
exactly
when
we
would
get
a
build
from
dotnet.
A
So
until
then
we'll
keep
the
api
as
part
of
the
like
open
elementary
api,
with
the
understanding
that
whenever
we
get
the
first
build
like
dotnet
six
built
of
system
diagnostic
source,
we'll
get
rid
of
it.
A
So
that's
just
an
update,
no
action
item
here
like
I,
I
will
start
submitting
like
actual
pr's
early
next
week.
Victor
would
also
be
working
on
that
as
well.
Okay,
I
had
like
one
other
things
which,
but
I
haven't
like
done
my
homework,
which
is
like
both
michael
and
alan,
would
reflect
that.
There
is
a
lot
of
discussion
going
on,
like
I
had
a
discussion
with
michael
offline
as
well
about
the
configuring
at
the
extension
start
hosting
package.
A
So
unfortunately
I
didn't
have
the
time
to
like
really
dig
into
it
to
respond
to
the
comments.
So
I
I
will
like
differ
this
to
another
week,
but
like
alain
or
michael,
if
you
have
like
anything
general
to
discuss
about
this,
I'm
like
happy
to
have
this,
since
we
do
not
have
any
other
topics
left.
E
C
A
Yeah
so
like
the
first
thing,
which
I
wanted
to
like
really
ask,
is
it
has
nothing
to
do
with
the
actual
microsoft
extensions
dot.
Sorry,
the
open,
elementary
dot
extension
slot
hosting
it
has
something
to
do
with
the
fact
that
the
default
trace
builder,
which
we
created
in
trace.
A
A
So
when
we
did
the
thing
we
did
asp.net
core
as
the
only
instrumentation
which
currently
supports
this
model
of
configuring,
but
like
it
had
an
sdk
dependency
for
some
other
reason-
and
I
just
like
built
on
top
of
it,
but
like
none
of
the
instrumentations,
either
in
the
main,
repo
or
contrib,
they
wouldn't
have
access
to
the
sdk
I
mean
they
shouldn't
have
so
we
need
to,
I
think,
michael,
like
we
discussed
like
there,
should
be
like
some
way
to
promote
this
into
the
api
itself.
A
But
then
we
will
have
to
like
sacrifice
this
part,
because
service
collection
is
not
part
of
the
building
thing
that
you
need,
like
microsoft.
Extensions
di,
but
service
provider
is
part
of
the
like
the
dot
net
runtime
itself.
So
we
shouldn't
need
like
any
extra
thing.
So
that's
like
one
problem,
because
without
solving
or
without
rather
moving
this
from
sdk
to
api,
we
cannot
really
build
like
the
same
instrumentation
configuration
experience
for
anything.
A
So
if
you
look
at
the
asp.net
core,
what
we
are
doing
is
we
check
if
the
default
tracer
builder
builder
is
being
used.
If
that's
the
case,
we
try
to
get
the
options
from
di
like
this
is
a
helper
method
which
looks
for
configuration
from
da.
So
that's
a
one
number
one
problem
it.
I
don't
think
an
issue
exists
for
this
I
mean
michael
and
I
discussed
this,
but
that's
about
it.
Second,
one
is
where,
like
these
peers
were
all
like,
all
competing
peers
are
trying
to
utter.
A
So
I
think
this
really
summarizes
like
the
most
of
the
issues,
and
one
thing
which
I
want
to
really
get
like
opinions
is
like.
Do
we
need
to
support
multiple
tracer
providers
in
the
extension.ta
package
I
was
trying
to
I
mean
I
was
in
initially
assuming,
even
though
I'm
still,
assuming
that
we
only
need
to
provide
the
helper
method
like
the
extension
stored
dpi
package
should
only
provide
the
like
mechanism
to
have
a
single
tracer
provider.
A
My
only
reasoning
behind
that
was
I'm
I'm
just
comparing
it
with
how
sp
net
core
deals
with
locating
it
doesn't
really
allow
you
to
replace,
or
it
doesn't
really
allow
you
to
have
like
multiple
logger
factories
in
the
same
application,
unless
you
do
like,
like
it
manually
without
using
the
built-in,
like
built-in
templates
or
built-in
logging
logo
factory,
it's
very
easy
to
create
like
if
you
have
a
console
lab,
you
can
create
like
a
number
of
logo,
factories
each
being
built
with
different
providers,
but
that
option
simply
doesn't
exist,
at
least
not
in
my
research.
A
A
We
should
like
make
it
that
if
you
call
like
multiple
call
store
services
stored
at
tracing,
it's
just
building
on
top
of
or
already
building
onto
the
existing
one.
That
was
my
initial
thinking.
That's
why
I
had
the
question
when
microsoft?
A
Okay,
if
you
have
like
multiple
providers,
which
one
should
the
config
be
applied
to
like,
if
you
do
like
services,
dot,
configure
zipkin
options,
which
z
kin
exporter
instance,
should
get
that
both
or
do
we
introduce
something
like
a
named
tracer
functionality,
so
that
whenever
you
do
something
you
have
to
specify
which
named
provider
that
this
is
applicable
to
so
the
first
thing
which
I
want
to
ask
is
like
what
everyone
thinks
about
making
it
making
the
expressions.a
package
only
support
the
single
tracer
provider
instance
approach,
and
if
some
advanced
user
really
wants
to
create
multiple
tracer
properties,
which
we
really
consider
like
an
advanced
scenario,
they
can
still
do
it
manually
without
using
the
extension
start
hosting
packages.
A
I
mean
I
I'm
asking
opinion
on
this
particular
question,
because
this
is
what
is
like
a
like
a
foundational
question
on
top
of
which
others
are
being
built.
Like
any
other
example
also
which
I
was
using
assumes
or
rather
assumed
at
that
time
was,
there
is
only
a
single
provider.
D
So
I
sort
of
challenge
your
analogy:
cjo,
because
with
the
logging
api,
it
makes
it
very
easy
to
register
multiple
logging
providers
under
the
one
factor.
So
we
don't
have
a
factory
concept
we
just
have
to
provide.
It
is
going
on
these
pr's.
Is
it's
very
easy
to
support
it
right
now
we
ignore
a
couple
of
the
other
things
we're
talking
about
it's
much
harder.
I
think
to
prevent
it
like
how
the
net
service
collection
works
by
default.
Is
you
can
register
as
many
as
you
want?
D
A
Yeah
I
mean
my
thinking
was
like
we
should
allow
like,
like
a
single
addition
like,
but
subsequent
ones
should
not
be
like
even
like
ad.
It
should
be
like
something
like
configure
open
elementary
tracing
as
supposed
to
add
so
people
can
like
call.
A
Yeah
we
cannot
prevent
someone
from
adding
twice,
but
what
we
can
do
is
like
make
the
second
ones
I
mean.
I
tried
to
mention
that
in
a
full
request,
like
what
I
I
had
in
my
mind,
but
let
me
just
open
it
see
if
it
makes
sense
but,
like
I
said,
I'm
not
like
really
opposed
to
that
multiple
providers
thing,
because
the
only
reason
is
it.
It
looked
to
me
like
hey.
It
was
confusing,
but
let's.
A
Yeah,
this
is
what
I
was
thinking
like.
If
you
call
it
like
multiple
times.
We
check,
if
it's
already
like
called
by
looking
at,
because
if
it
is
indeed
called,
we
would
be
registering
one
service
of
the
type
implementation
type
telemetry
hosted
service.
So
we
can
use
that
as
a
marker
to
indicate
if
it
was
called
or
not,
and
if
it
is
called.
Let's
say
this
is
the
second
code,
so
user
has
a
like
action,
so
we
don't
lose
it.
A
So
we
just
like
apply
it
so
that
when
the
final
thing
is
being
built,
it
would
be
a
cumulative
sum
of
all
the
ad
open
elementary
tracing.
But
finally,
you
still
have
a
single
provider,
but
I
know
that
this
is
like
really
weird.
I
mean
I
came
up
with
this
because
this
is
how
applications
it
was
dealing
with
this
problem.
It
doesn't
allow
multiple,
the
equivalent
of
tracer
provider,
is
telemetry
client
in
app
insights.
It
only
allows
a
singleton
to
be
added.
A
So
if
you
call
like
this
n
times,
we
detect
that
it
was
already
added
and
bailout,
but
that
doesn't
mean
that
we
should
follow
it
in
open
telemetry.
That
that's,
that
was
my
original
thinking,
which
made
me
write
this
statement
and
but
like
based
on
what
michael
says
like
it's.
It's
like
the
incorrect
way
of
dealing
with
di
because
since
nativity
allows
things
to
be
added
like
a
number
of
times,
we
should
not
do
like
anything
unnatural
to
prevent
we
just
added
as
many
number
of
times
as
user
calls
it.
A
D
It
manages
the
factory
and
then
you're
just
adding
in.
However
many
providers,
you
want,
through
its
extensions
and
then
sort
of
the
runtime,
takes
care
of
okay.
You
asked
for
four
or
five
now
I
own
the
factory,
I'm
gonna
make
sure
those
four
or
five
are
created.
You
know
they
live
and
then,
when
the
factory
is
disposed,
they're
all
cleaned
up,
so
we
might
be
able
to
do
something
similar
to
that.
I.
A
See
let
me
see
if
I
really
understood
what
you're
saying
so,
okay,
not
here
like
when
you
say
like
logging,
like
you
mean
like
how
loader
does
it
so
like
this
is
where,
like
you
typically
configure
like
logging,
like
a
builder
like
here,
like
you'll,
have
a
configure
login.
So
in
that.
B
A
Configure
logging
call,
I
think,
yes,
yes,
login
call
and
the
only
thing
which
you
have
access
to
is
the
login
builder.
So
you
like
call
like
loginbuilder.addconsole.debug.
D
B
A
Yeah-
and
there
is
no
like,
whenever
you
add
any
program,
it's
all
like
being
tied
to
the
same
factory-
there
is
no
way
you
can
create.
Like
a
second
factory
by
mistake,
you
could
go
out
of
your
way.
I
think
you
could
new
one
up
yeah,
you
can
do
like
logo
factory.create
but
like
if
you
stick
with
the
like
extension
methods
on
hosting
or
di
like
service
collection,
there
is
no
way
because
anytime,
you
call
it
like
configure
logging.
It
gets
like
chained
into
the
previous
one.
B
A
I
think
I
mean
I
I
had
it
like
different
thinking
actually.
So
when
I
compare
the
way
I
logger
deals
with
this,
for
me,
it
looks
like,
and
I
logger
provider
is
more
comparable
to
a
processor
kind
of
thing
where
you
specify
like
a
destination
for
your
logs.
Like
add
console
means
you
just
it's
in
the
equivalent
of
like
tracing
it's
as
good
as
adding
like
add
console
exporter.
A
So
I
was
assuming
that
since
no
matter
how
many
no
matter
like
how
many
times
you
call
like
configure
logging,
it
gets
all
sticked
into
the
same
logo
factory
and
there
is
a
single
logger
factory
and
it
does
not
allow
you
to
create
a
separate
one
using
da.
You
can
of
course,
manually
create
it.
A
So
I
I
was
trying
to
compare
the
open,
telemetry's
tracer
provider
with
I
loggers
logger
factory,
because
both
holds
the
configuration
on
where
the
telemetry
should
be
sent
and
by
that
comparison
like
like
I
logger
is
doing
like
is
only
allowing
a
single
dogger
factory.
So
by
that
logic
is
what
I
in
earlier
commented
that
we
should
allow
a
single
tracer
provider.
A
A
So
it's
kind
of
in
duty
that
when
you
do
like
configure
you're
not
like,
I
mean
it's
kind
of
intuitive
that
you
are
configuring.
An
existing
dog
you're
not
like
adding
a
brand
new
thing.
A
Does
it
make
sense
or
like
did
I
just
like,
like
confuse
everyone.
C
C
C
I
think
if,
if
I
remember
right,
seem
to
seem
to
give
me
the
impression
that
at
least
to
this
person
that
if,
if
I'm
reading
their
issue
correctly,
it
seems
that
this
person
would
expect
that
multiple
calls
to
add
open,
telemetry
tracing
would
all
be
operating
on
a
single
provider,
and
part
of
me
wants
to
say
that's
my
intuition
too,
but
you
know
I.
I
was
similarly
trying
to
think
of
other
cases
like
logging
or
another
example
I
thought
of,
and
I
don't
know
what
would
happen
but
like
in
an
mvc
app.
A
I
see
yeah
I
mean
I
mean
this
use
case
is
exactly
what
you
are
like
describing
he
was
expecting
that
his
final
application
is
built
by
like
smaller,
like
individual
components,
and
everything
like
every
component
adds
something
to
the
overall
pipeline,
like
some
of
them
may
be
adding
like
an
exporter.
A
Some
of
them
may
be
adding
enabling
some
instrumentation,
so
he
was
expecting
that
they
could
do
that
like
cumulatively,
so
they
were
all
like
doing
like,
add
open,
telemetry
tracing
and
one
they
would
add,
like
provider
dot,
oh
sorry,
builder,
dot,
add
instrumentation,
xyz
and
another
guy
would
add,
like
builder
dot,
add
instrumentation,
but
in
effect
what
they
were
doing
was
each
god
would
create
any
separate
instance.
So,
at
least
from
my
understanding
of
discussing
this
with
him
like
year
back,
he
mentioned
that
his
intuition
was.
A
It
would
all
be
like
cumulatively
added
to
the
same
thing
as
opposed
to
building
like
separate
thing,
but
I
I
could
easily
argue
that,
like
the
name
is
like
add
not
like
configure
so
name
like
the
english
name,
ad
means
you
are
adding
more.
A
So
that's
like,
I
think,
michael,
had
a
different
solution
for
this
kind
of
use
case
like
if,
if
like
a
single
place,
holds
the
add
open
elementary
tracing
and
there
are
like
10
different
teammates
writing
their
own
extension.
Then
they
should
all
write.
Extensions
on
builder,
like
builder
dot,
add
my
thing
and
inside
that
they
can
do
whatever
they
want,
like
adding
an
export
or
instrumentation,
but
there
would
still
be
a
single
at
open
elementary
tracing
called
internally.
A
It
could
code
like
each
of
them
like
one
by
one
like
builder
road,
add
custom
extension,
one
custom
extension
to
that.
That
was
your
idea
right,
michael
right,
like
instead
of
like
really
I
mean
that
would
be
the
right
way
of
solving
this
problem.
So
you
would
only
have
like
a
single
chord,
that's
a
normal
case
and
any
any
additional
any
other
additional.
Like
sub
team
you
have
which
may
want
to
add
telemetry.
They
should
write
extension
method
on,
like
tracer
provider
builder.
D
Yeah,
so
what
I
try
to
avoid
is
like
startup
spaghetti
code,
where
somebody
goes
into
the
startup
file
and
at
the
top
they
might
be
adding
something
on
the
on
the
builder
and
then
in
the
bottom,
they're,
adding
some
singleton,
maybe
they're,
adding
a
scope
service.
So
there's
like
four
different
lines
in
that
soup
that
are
relative
to
one
thing
going
on
for
open
telemetry.
D
So
what
I
try
to
do
in
my
code,
reviews
is
say
like
okay,
let's
make
an
extension,
so
it's
one
line
and
then
that
one
call
is
configuring
all
the
services
that
are
required,
as
well
as
impacting
the
builder.
So
it's
just
very
clear
when
you're
reading
the
code,
what
what
goes
to
what?
What
matches
up.
A
D
That
I
tracer
deferred
thing
is
you?
Can
you
have
the
service
collection?
So
if
you
need
to
do
any
service
as
you
can
and
then,
if
you
need
to
register
a
configuration,
you
can
do
that
as
well,
so
that
you
couldn't
do
that
before
now,
you
can,
if
you
have
the
sdk,
you
can
write
an
extension
that
does
all
that
stuff.
It
sets
up
all
the
services,
maybe
registers
a
hosted
service,
a
couple
singletons,
and
then
it
does
a
processor
or
a
sample
or
whatever
it
needs
for
open
telemetry
and
it
all
works.
C
I
think
yeah,
you
know
I'm
I'm
I'm
familiar
with
this
spaghetti
startup
code.
I've
seen
examples
of
that
for
sure,
and
I
guess
on
that
note
one.
You
know
one
thing
that
I
I
think
I've
seen
is
where,
and
maybe
maybe
this
this
is
what's
going
on
in
this
guy's
environment.
Is
you
know?
Maybe
one
team
is
developing,
like
a
portion
of
the
startup
class,
basically
like
a
base
class
that
all
the
other
teams
just
consume
and
it's
a
effectively
a
black
box
to
them
in
that?
C
A
The
same
use
case,
which
this
guy
has
mentioned
like
he,
has
like
different,
like
sub
teams,
each
of
them
building
an
extension
method
on
to
add
like
certain
aspects
of
the
instrumentation
or
certain
aspects
of
open,
telemetry
like
being
an
exporter
or
like
adding
like
some
special
instrumentation.
So
this
is
exactly
what
you
are
describing
like
same
situation.
I
have
seen
it
like
many
people,
like
writing,
wrappers
around
telemetry
libraries,
to
give
it
to
their
team
and,
like
then,
several
people
write
similar
extensions
and
then
like
the
final
like
owner.
A
They
will
just
call
like
each
of
these
extension
methods
or
each
of
their
like
wrappers
and
ultimately
they
expect
they
would
be
like
accidentally
creating
different
providers
by
doing
that.
So
that's
that
was
like
part
of
my
original
reason
why
I
was
like
I.
I
was
opposed
to
saying
like
if
you
allow,
like
multiple
providers,
then
like
it's
kind
of
not
what
people
were
expecting,
but
they
just
got
it
like
as
a
side
effect
of
they're
doing
like
something
else,
which
is
what
we
want
to
over.
A
That's
one
of
the
reason
why
I
said
we
should
try
to
prevent
multiple
calls
to
add
like
adding
more
and
more.
Instead,
it
should
just
like
stick
with
the
same
one,
which
was
added
originally
and
built
onto
it,
but
I
I
don't
really
I
mean
I
haven't
really
thought
about
the
like.
A
We
did
not
have
the
idea
for
tracing
builder,
which
had
service
collection,
so
maybe
like
micro
solution,
is
the
right
way
like
if
you
want
to
like
build
it
like
that,
then
you
should
ask
your
teammates
to
provide
extension
methods
on
ida
for
tracing
provider
builder,
and
you
should
like
consolidate
all
the
codes
and
code
like
one
uber
thing
which
calls
like
like
add,
open
elementary
tracing
internally
once
and
within
that,
as
the
action
you
can
call
like
builder,
load
all
the
extension
method
that
should
at
least
solve
this
problem.
A
If
we
all
agree
with
that,
then
the
second
problem
is
already
solved,
which
is
we
allow
multiple
calls
to
add
open
elementary
tracing.
It
should
be
setting
its
own
provider,
but
we
don't
expect
people
to
do
that
and
we
don't
prevent
anyone
from
doing
that
either
and
we'll
apply
the
fix
which
michael
proposed,
like
we
retrieve
immunity
of
tracer
provider.
So
we
can
dispose
each
of
them
not
just
the
first
one.
B
B
A
D
A
But
that's
a
separate
example:
that's
a
generic
question
of
like
why.
Why
do
someone
want
like
multiple
properties
in
the
first
place,
like
that?
That
means.
A
But
this
like
the
extensions
hosting
issue,
is
not
really
reliable,
because
I
mean
I
mean
it's
a
lighter
in
the
sense
that
it's
related
to
like
multiple
tracer
providers,
but
that
I
said
like
in
the
original
example.
It
is
by
intention
that
you
are
creating
multiple
providers,
because
you
want,
like
things
to
happen
certain
way,
but
most
common
cases.
E
A
You
want
like
a
single
thing:
if
you
want
like
multiple
back-ends,
I
mean
or
multiple
exporters,
you
just
build
onto
the
same
one
like
you
have
the
ability
to
like
add
exporter.
One
add
exporter
to
and
you
can
do
like
any
filtering
in
individual
pipelines
like
one
with
higher
filtering
one
go
into
a
expensive
exporter
and
another
one
which
is
like
not
filtering
at
all
and
sending
to
a
like
very
cheap
exporter.
A
So
you
don't
really
need
multiple
providers
there,
but
I
mean,
if
someone
needs
that,
then
they
understand
the
consequence.
They
are
explicitly
asking
two
providers,
because
the
configuration
is
indeed
different,
like
specifically
like,
in
that
case,
like
sampling
or
like
some
filtering
kind
of
thing,
but
that's
like
not
the
most
common
scenario
like
most
commonly
people
would
have
just
like
a
single
tracer
provider.
A
So
my
I
mean
this
is
what
you
are
saying
like
the
right
solution
for
the
issue
which
is
opened
earlier.
So
if
a
team
member
wants
to
do
something,
they'll
just
do
like
extension,.
A
And
if
you
I
mean,
if
you
have
like
different,
like
extensions
like
that,
you
should
all
call
it
like
here
rather
than
coding
like
like
n
times,
because
if
you
are
calling
it
10
times,
it
is
indeed
multiple
providers.
A
You
are
basically
proposing,
like
called
extension
methods
on
the
builder
like
here
within
the
single
code,
that
should
satisfy
the
need
for
maturity
of
the
user.
And
if
you
are
like
really
advanced
and
you
want
multiple,
then
then
you
would
call
like
the
second
and
third
options
or
as
many
times
as
you
need.
Is
that
your
understanding
as
well.
D
I
think
so,
yes,
okay,
because
I
mean
if
we
are
going
to
support
multiple
and
I
think
we
have
to
then
how
I
think
it's
really
hard
to.
Let
people
writing
libraries
like
they
just
don't
have
enough
information
to
choose
the
correct
one.
So
I
think
we
have
to
kind
of
put
them
in
a
place
where
whoever's
bootstrapping
that
application
ultimately
has
to
decide.
A
A
Yeah,
but
this
yeah,
this
looks
like
the
most
correct
one,
but
I
mean
we
probably
don't
have
the
motivation
to
do
like
something
like
this,
because
this
is
like
really
a
like
less
common
scenario.
C
You
know
this
is
this
is
a
little
bit
tangential,
but
your
point
about
you
know
people
this
well,
this
being
an
advanced
scenario
where
people
are
going
to
like
a
shipping
data
to
a
cheap
back
end
and
like
a
more
expensive
back
end.
C
I
think
a
common
solution
that
people
are
going
to
employ
in
that
scenario
is
actually
run
their
own
open,
telemetry,
collector
and
like
run
like
a
tail-based
sampling
or
something
like
that,
and
they
can
run
that
locally
in
their
in
their
local
network
and
then
ship
to
their
more
expensive
back
end
that
way,
anyways
that
was
kind
of
an
aside,
but
it
just
made
me
think
about
that.
Yeah.
A
A
Like
have
like
some
examples
running
like
that,
it's
you
don't
really
need
the
collector
part.
A
You
can
use
like
the
notion
of
filtering
processor,
where
you
can
do
that
post
or
tail-based
sampling
as
a
like
filtering
processor,
and
you
can
set
up
like
multiple
pipelines
in
the
same
tracer
provider
and
one
will
not
be
having
this
filtering
thing
so
like
basically,
let's
all
the
traces
go
and
then
the
second
pipeline
within
the
same
provider
will
have
the
filtering
processor,
which
will
like
or
like
post
tail
based
sampling,
which
can
do
like
some
more
intelligent
sampling
and
let
only
the
critical
traces
to
go
to
the
expensive
store.
A
So
you
can
do
that
without
setting
up
multiple
profile.
Programs,
like
you
said
like
send
everything
to
like
collector
and
from
the
collector,
do
that,
like
post
sampling
and
then
send
it
to
different
backends.
A
Okay,
like
let's
do
one
thing
like.
Let
me
write
like
consolidate
this
discussion
into
an
issue
and
write
some
examples
and
see
if
anyone
else
gets
into
a
different
opinion,
because
because
I
mean
this
sounds
intuitive,
when
you
have
a
case
where
we
really
need
two
providers.
B
A
Really
allows
you
to
have
multiple
providers,
and
one
like
from
these
cases
would
be
like
you
want,
like
some
providers
to.
Let's
say
you
have
library,
one
and
two,
and
you
want
elementary
from
library,
one
to
only
flow
to
a
particular
provider
like
you,
basically,
at
least
in
dotnet.
We
allow
that
ad
source
thing,
so
you
create
one
provider
for
source,
one
or
library,
one.
You
create
another
provider
for
second
library
or
second
source,
so
they
kind
of
flow
somewhat
independent
of
each
other.
E
May
I
add
something
here
I
I
was
speaking
to
bogdan
about
topic
similar
to
this
previously
about
whether
or
not
we
have
one
one
trace
provider
or
two
trace
provider,
and
at
least
the
answer
that
I
recollect
him
saying
is
that
if
the,
if
the
concern
was
only
to
be
able
to
send
some
telemetry
to
one
exporter
versus
other
telemetry
to
other
exporter,
I
think
his
his
recollecting
what
his
what
he
said
was
that
he
believes
that
that's
really
more
of
a
configuration
of
the
exporter
rather
than
of
the
trace
provider.
E
In
other
words,
in
that
particular
case,
you
would
still
have
one
trace
provider,
but
when
you
add
multiple
exporters
and
when
you
add
the
exporter,
you
would
configure
it
to
filter
just
for
that
exporter.
So
from
that
perspective,
at
least
for
the
case
that
I
heard
about
sending
data
to
different
exporters,
you,
I
don't
necessarily
think
you
need
multiple
trace
providers.
Yeah.
You.
A
I
mean
now
that
brings
the
question
like
we
should
probably
be
able
to
like
have.
I
mean
actually
almost
all
the
scenarios
by
just
using
different
pipelines
within
the
tracer
provider,
which
brings
the
original
question,
which
michael
was
asking?
What
is
a
true
scenario
where
one
would
really
need
to
set
up
multiple
tracer
providers.
E
E
A
A
I
think
we'll
write
some
examples,
because
these
there
isn't
enough
examples
to
really
like
demonstrate
some
of
the
issues
it's
like
spread
into
several
issues
and
pr
so
try
to
like
put
them
into
a
single
issue
using
examples
from
here
and
other
issues
and
then
see
if,
like
we
can
have
like
a
more
streamlined
discussion
like
where
we
can
like
put
like
checkbox
okay.
Does
it
meet
this
pro
or
does
it
solve
this
particular
problem?
A
Where
you
can
build
things
like
cumulatively
or
then
there
was
other
issues
which
I
mentioned
like
in
application
sites.
People
are
used
to
doing
things
like
you
just
add
like
ad
application
sites,
and
then
it
just
picks
up
every
processor
from
the
da.
You
just
add,
like
services
to
add
processor
to
the
da,
and
we
just
pick
it
up,
but
if
it
is
just
like
an
application
set
specific
thing
I
don't
want,
I
mean
I
don't
think
it's
a.
A
It
makes
sense
for
open
telemetry
to
support
that,
but
I'll
see
like
if
there
is
any
other
scenarios
where
this
might
be
required.
Then
I'll
try
to
put
that
in
the
example
as
well
and
then
we
can
have
like,
like
we
can
pick,
which
pr
makes
I
mean,
which
pr
addresses
the
problems,
and
then
we
can
go
from
there.
A
So
I'll
put
some
notes
here
I
mean.
Basically,
the
main
action
item
is
for
me
to
like
document
the
examples
and
see
which
approach
solves
this
problem
or
say,
which
means
see
whether
those
scenarios
are
already
addressable
with
the
current
code
without
merging
any
of
the
like
pending
pr's
and
then
because
some
of
the
issues
were
open
much
before
the
deferred
builder
was
there.
A
So
I
try
to
collect
that
into
a
single
issue
separately
or
maybe
related
the
I
deferred
provider
being
in
the
sdk
is
still
a
like
non-issue.
So
if
you
want
to
like
support
deferred
configuration,
you
need
to
get
a
reference
of
the
sd
to
the
sdk.
A
D
Okay
sounds
good,
yeah,
okay,.
A
A
Okay,
thanks:
everyone
see
you
next
week,
bye-bye.