►
From YouTube: 2023-02-21 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
D
B
Yes,
nothing
goes
there,
so
probably
we
can
like
triage
any
issues
which
might
block
1.4
or
delay
and
I
mean
look
at
the
open
issues
and
see
if
anything
would
be
needed
to
be
addressed
before,
because
by
default,
our
plan
is
to
ship
it.
This
Friday.
C
C
B
C
This
is
Auto
instrumentation
problem.
A
B
B
B
B
F
B
E
D
B
Yeah,
so
the
documentation
should
suggest
that
your
custom
components
should
take
care
of
disposing
the
things
it
brings
pulling
dispose
on
your
custom
opportunities,
the
responsibility
of
SDK.
So
something
like
that.
Okay,
you
can
discuss
on
the
pr.
C
B
C
C
B
B
Would
probably
know
faster,
he
like
plans
to
you
know
if,
okay,
it
looks
like
we
are
now
we
are
creating
client,
but
it
will
be.
B
It
plans
to
reflect
anything
about
a
girl
attempting
to
connect
in
the
startup.
G
I,
don't
really,
but
it
is
a
UDP
socket,
so
I.
Don't
think
that
connect
really
does
anything.
I
mean
UDP
just
writes
out,
it
doesn't
care
if
they're
the
response.
B
Is
it
just
download,
is
it
like
if
they
can
Auto
folder,
DNS
folder
that
holds
to
you
they
are
cutting
page
and
host
and
what
okay.
B
Yeah
but
the
question
was
like
it's
a
behavior
change,
which
we
added
recently
because
we
were
not
crushing
earlier.
We
added
it,
but
we
decided
it
was
the
right
thing
to
do.
If
we
expect
open
Elementary
sdks
to
follow
the
general
error
handling
guideline
and
try
to
fail
for
us,
so
we
are
doing
it
for
a
reason:
I,
don't
know
what
would
be
do
otherwise.
G
C
B
A
C
Dots
got
it
do
we
know
which
PR
that
was
changed,
and
that
sounds
familiar
now.
Yeah.
B
B
F
B
B
B
C
Foreign
I
think
what
he's
saying
is
like
so
like
the
team
who
who
writes
this
code
is
not
the
team
that
then
ultimately
like
manages
the
service,
and
so
so
they'd
like
that
team
to
just
like.
If
this
doesn't
work
for
whatever
reason
they'd
like
effectively
an
option
should
just
be
like,
we
don't
need
open,
Telemetry,
then
I
guess.
A
A
F
C
Yeah
I
think
yeah,
absolutely
I,
think
that
would
fix
their
problem,
but
I
I
wonder
if
that
would
be.
If
it's
still
like
some.
Like
you
know,
we
have
like
that
blanch
who
had
opt-in
something
a
while
ago
to
prototypes
like
the
SDK,
enabled
disabled
type
of
thing
via
environment
variable.
A
C
I
can
see
a
team
like
in
a
hops
team
like
this
wanting
to
just
say,
like
just
disable
the
SDK
like,
so
we
can
get
the
service
running,
yeah,
I.
G
Have
had
that
request
for
an
SDK
disabling
feature,
I'm
going
to
come
up
a
few
times.
The
first
time
was
with
auto
instrumentation
there's
an
issue.
I
was
working
on
about
it,
we're
just
looking
at
it
for
the
Azure
sort
of
meta
package
thing
so
I
think
that
would
be
something
useful.
Maybe
we
can
look
out
for
1.5.
B
Yeah
that
issue
is
already
open,
like
I
think
we
already
have
that
issue
open
from
the
auto
instrumentation
report.
Okay,
so
do
we
just
close
this
thing
that
this
is
the
expected
Behavior?
It
was
working
earlier
because
we
did
not
handle
that
field
first
methodology
in
hosting
package,
and
it
was
your
reality.
Okay,
yeah!
Maybe
you
can
say
that
if
you
use
the
regular
SDK
style,
it
was
already
the
behavior
only
for
hosting
we
had
to
like
fix
it
recently
with
that
yeah.
B
B
B
Those
are
two
examples,
so
we
have
that
opened
in
the
contract
report
and
I
think
we
have
a
general
agreement
that
we'll
hosted
in
the
main
report
because
they
are
built
purely
based
on
the
components
from
the
main
requirement.
If
the
examples
get
like
too
much,
then
like
we'll
consider
moving
it
to
a
dedicated
triple
so
for
now,
I
asked
him
to
open
APR
in
the
same
report
in.
F
B
B
Maybe
like,
if
you
do
like
something,
we
should
be
like
very,
very
explicit,
saying
that
this
is
absolutely
a
one-off,
because
this
is
broken.
This
is
taking
the
absolute
basic
scenario
we
are
considering
a
fix.
It
should
not
be
interpreted
as
we
are
going
to
actively
address
any
requirement
issues,
because
otherwise
we
we
can
expect
like
if
someone
start
testing,
they
might
find
like
more
and
more
issues
and
then
we'll
be
always
constantly
like
fighting
this
battle,
because
there
is
no
way
we
can
take
it
in
CA
right
now.
B
C
Yeah
I
think
that
makes
sense.
I
think
this
is
worthy
of
at
least
looking
at
and
seeing
if
it's
an
easy
fix
and
dealing
with
it.
D
So
does
the
the
screenshot
shows
it
failing
at
get
hash
code
for
tags,
yeah.
B
D
B
Of
all
the
custom
tags
which
the
user
needs
so
workaround
is,
they
can
put
a
dummy
view
which
yeah
with
the
tag
which
matches
whatever
they
are
intending
to
pass,
that
that
would
work
around
the
problem.
But
it's.
B
Okay,
yes,
strings
would
be
null
by
default
if
they
are
using
the
non-view
approach
or
even
if
they
use
view,
if
they
did
not
specify
the
like
the
special
tags,
then
it's
going
to
be
null.
C
B
C
B
But
I
want
to
like
hear
from
like
everyone
like
what
should
be.
The
general
policy,
like
should
be
I,
think,
rightly
responded
with
his
opinion
in
the
issue
itself,
saying
that
no,
we
don't
because
we
already
explicitly
State.
We
only
support
what
supported
by.net.
B
The
only
thing
is
like
in
the
I
think
the
announcement
where
we
mentioned
that
it's
technically
possible
to
run
it
with
a
statement
following
that
saying
that
we
never
tested
it
so
yeah.
So
it's
more
like
we
cannot
completely
ignore
it,
but
at
the
same
time
we
don't
want
to
be
like
doing
it
forever.
So
maybe
Alan
like.
Can
you
open
that
that
3767,
the
discussion
you
had
opened
yeah
yeah,
maybe
like
we
could
refactor
this
in
some
way
to
be
like
more
strongly
warning
against
this
thing,
foreign.
C
A
C
B
It's
technically
consumed
in
the
sense.
Yes,
you
can
build
it.
Matrix
break
broke
like
the
I
think,
the
other
part
traces
should
be
working,
but
again
we
haven't
tested.
So
we
can't
be
very
sure.
C
D
B
C
I
think
that's
fair
I
mean
yeah
for
for
this
specific
issue,
I,
don't
know
it
wouldn't
be
opposed
to
just
fixing
it,
though
this
is
didn't.
We
didn't.
We
change
a
bunch
of
the
git
hash
code
functions
across
numerous
places
so
like
this
may
just
be
one
place
and
then
he'll
just
encounter
in
another
place.
That's.
B
Why
I
said
like,
if
you
fix
it
like
you,
should
be
like
very
like
documenting
in
the
period
itself,
that
or
in
the
issue
itself
that
we
do
not
intend
to
fix
any
more
issues
in
net
core
3.1,
given
it
sort
of
support,
but
this
is
being
considered
for
because
it's
breaking
like
the
very
basic
hello
world
metric
yeah.
B
Won't
help
right
like
if,
if
the
team
like
they
continue,
testing
with
this
bug
is
fixed
and
they
may
find
like
more
issues
later
in
somewhere
in
metrics
or
some
some
places
elsewhere.
So
we
might
get
that
same
question
so
I'm
now,
thinking
like,
if
you
do
it
like
one
time,
maybe
we'll
be
like
forced
to
do
it
more
and
more
yeah.
B
We
should
just
say
no
anyone
else
like
with
some
ideas
on
this
one
like
I,
don't
know
like
what
should
be
like.
Should
we
be
like
because
from
day
one
like
we've
been
trying
to
state
that
very
clear,
like
we
only
supported.net
runtime,
if
it's
officially
in
the
supported
life
cycle
by
dotnet
itself,
so
we
actually
did
a
lot
of
effort
to
support
net
452
just
because
it
was
supported
by.net.
B
If
you
look
at
AV
other
libraries
like
Prometheus
all
those
things
they
never
supported
like
that
far
back,
so
we
actually
need
some
extra
effort
to
support
all
the
things.
So
we
are
still
following
that
principle.
So
that's
it
by
that
logic,
I
think
we
should
just
stick
toward
it,
saying
that
will
be
do
not
enter
to
fix
it
and
give
the
wrong
message,
because
we
don't
have
a
way
to
test
it
going
forward,
so
there
might
be
other
things
broken
and
we
can
release
it
if.
E
We
have
the
same
in
the
instrumentation
directories.
We
added
net
standard
to
zero
and
to
one
just
to
support
net
core
2.1
I
believe
and
some
of
the
things
that
I
was
looking
at
are
not
supported
in
net
standard
2.0,
so
I
think
like
if
we
say
it
here
like
we
don't
support
network
3.0,
then
we
may
consider
just
removing
it
from
the
instrumentation
libraries
as
well.
E
We
added
it
back
one
time
like
one
time
back,
I
removed
it,
but
then
I
added
it
back
like
in
all
I
think
both
of
them
like
ESPN,
core
and
HTTP
9,
so
that
that's
the
same
issue
like
some
of
the
things.
B
C
Yeah,
this
is
all
related.
I
think.
The
reason
why
we
added
it
back
was
was
exactly
this
was
that
we
we
decided
to
keep
net
standard
targets
so
that
people
could
continue
to
function
in
a
you
know,
non-like
official
supported
way,
but
you
know
if
it
turns
out
that
we
do
have
core
issues
with
running
on
net
3.1
netcore
3.1,
and
it
basically
makes
it
not
work.
Then
we
might
want
to
reconsider
our
net
standard
targets,
just
remove
them
across
the
board.
B
Yeah
I
mean
I
mean
the
in
the
issue
or
the
announcement.
You
have
made
it
clear
that
we
haven't
not
tested
it,
so
maybe
we
should
highlight
it.
It
basically
says
you
can
compile
it.
It
won't
break
because
of
the
next
standard
Target
being
there,
but
everything
else
is
really
like
not
tested,
so
it
may
work.
It
may
not
work
something.
That's
the
thing
which
is
confusing
this
is
they
say
that
we
State
usable,
but
it's
completely
unusable.
So
maybe
we
could
make
the
warning
stronger.
C
B
Know
so
I
like
one
suggestions,
announcements
right
now,
but
then
let's
move
this
into
a
dock
itself,
so
we
can
deal
with
it
with
PRS,
so
people
know
the
history
and
because
it's
announcements
right
now
right,
you
can
still
see
the
history.
B
It's
usually
we
have
a
versioning
doubt
maybe
like
we
could
put
like
some
content
from
it
into
the
versioning
dock
itself,
and
that
way
like
people
can
comment
like
if
someone
is
changing
it.
So
it's
a
more
informed
decision
as
opposed
to
editing
announcement
which,
like
I,
think
anyone
with
approval
or
maintainer
can
simply
go
and
delete
yeah.
B
Since
it
is
more
like
a
policy
thing,
we
should
try
to
do
like
more
into
a
PR
world
where
we
can
move
some
of
this
into
a
versioning
dock
and
then
I
mean
the
questioning
dog
already.
Is
there
steal?
Some
of
this
content
incorporate
that
into
that
dog
and
after
that
we
can
continue
to
edit
that
document.
So
whenever
we
make
some
big
changes
like
that,
it
could
be
through
peers.
C
B
C
B
B
We
support
what
support
okay,
that's
it
the
very
first
statement
in
the
main
readme
yeah,
and
then
there
is
versioning
details
so
that
we
could
see
if
we
can
fit
this
somewhere
here,
because
mostly
done
for
like
how
do
we
version
like
our
own
versioning
itself,
not
really
talking
about
what
version
of.net
runtime
we
support,
but
basically
everything
we
could
use.
The
same
note
put
a
new
section.
B
And
we
could
also
like
another
potential
content.
Is
that
if
you
remove
a
Target,
we
do
it
with
a
minor
version
change,
not
major
percentage.
We
do
that
only
when
the
runtime
itself
is
going
out
of
support.
So
we
do
have
like
something
like
that
in
our
change
load
like
several
times,
maybe
a
good
thing
to
put
it
into
one
place,.
C
A
B
D
Yeah
I
didn't
clearly
I
mean
I.
Think
I'll
go.
Maybe
do
a
Repro
myself
to
understand
why
that
failed.
I
cannot
like
recall
the
code
where,
like
how
it
flows
to
Matrix
team
identity,
and
why
would
it
fail
on
netco
3.1,
but
like
are
we
saying
that
we
would
probably
start
supporting
3.1
later
on?
If
no.
B
Maybe
Let's
refine
the
message
a
little
bit
more
clear
yeah.
We
still
do
not
intend
to
support.net
core
3.1,
given
I
mean
in
alignment
with
our
general
support
policy,
yeah
just
to
be
absolutely
clear,
like
let's
not
give
false
hopes
to
people
that
might
be
motivate
them
from
moving
away
from
document
code
3.1,
you
don't
want
to
be
the
three
cents
over
there.
B
We
should
look
out
like
these
issues
and
accidentally
fixed
it,
even
though
we
did
not
really
tend
to
fix
it.
We
would
have
fixed
it,
but
several
months
ago
only
the
announcement
was
certain
days.
So
payment
was
on
the
1.4
like
the
test.
They
would
have
already
complained,
but
I
don't
think
we
received
much
complaints.
D
C
D
B
C
B
C
B
Yeah
and
like
Ellen
like,
if
you
get
a
chance
like,
can
you
get
a
like
sense
of
how
many
are
still
using.net
course,
improvement
from
your
Telemetry
I
mean
I.
Don't
intend
that
to
be
a
decision
Factor,
but
at
least
we
should
be
doing
like
how
many
of
them
would
be.
Would
we
be
breaking
by
shipping
control.
C
That
I
pulled
was
not
in
the
context
of
open
Telemetry.
It
was
in
the
context
of
folks
using
general
urelic.net
agent,
which
you
know
may
be
a
different
population.
I,
don't
know
if
it's
representative
of
the
open,
Telemetry
population
but
I
think
what
you'll
find
is
that
there's
still
a
lot
of
people
using
you
know.net
core
2.0,
much
less
3.1
today.
F
F
Of
this
I
just
feel,
like
maybe
I
mean
this
is
just
my
opinion,
like
if
I'm
running,
a.net
tool,
app
I'm,
not
making
any
changes
to
that
app
like
I'm
I
haven't
upgraded
because
my
thing
is
effectively
a
legacy
and
there's
just
no
reason
for
me
to
make
any
changes
to
my
app.
So
I
would
never
consider
upgrading.
F
C
I
think
that
totally
makes
sense
to
me
too,
especially
for
consumers
directly
of
the
open,
Telemetry
SDK.
The
the
one
area
that
I
kind
of
wonder
if
this
will
become
more
of
an
issue,
is
the
auto
instrumentation
so,
like
another
team,
basically
wanted
to
use
open
Telemetry,
and
they
just
you
know,
automatically
use
this
agent,
hoping
that
it's
going
to
work
for
one
a
bunch
of
their
older
apps
with
no
code
change
whatsoever.
C
If
that's
where
we
might
start
to
experience
correction,
because
great,
that
would
be
more
similar
to
like
the
new
relic.net
agent,
like
those
numbers
that
I
that
I
pulled
the.
B
But
for
those
customers
like
in
order
to
instrumentation,
they
can
use
the
old
version
while
they
they
can
still
get
something
together
like
they
can
totally
use
an
old
version
of
SDK.
Also,
we
won't
be
doing
quad
fixes,
but
they
got
any
way
using
a
version
of.net,
which
itself
does
not
see
what
fixes
so
missing,
hotfix
and
open
delivery.
You
should
not
break
inside,
so
they
can
easily
use
the
old
version
of
SDK
of
what
instrumentation
we
support.
Server
version
of
50.
B
So
here
like
like,
like
just
like
Daniel
saying
like
if
they
are
choosing
to
update
from
open,
Elementary,
1.2
or
1.3
to
a
newer
version,
that
means
they
are
actively
like
doing
something
with
their
legacy
application.
This
means
at
that
point
they
should
consider
moving
from
the
unsupported.net
itself.
Otherwise
they
should
just
leave
it
and
just
do
an
update,
open
element
right
itself
right.
B
C
C
Yeah
I,
don't
I
don't
disagree
with
any
of
this
I.
Just
you
know,
am
anticipating
what
our
future
feedback
might
look
like
and,
of
course
you
know
at
the
end
of
the
day,
that's
what
should
drive
us
to
to
move
I.
Think
I.
Think
the
position
as
you've
stated
at
CJ
and
Dan
is
totally
legit
and
should
be
our
message
Continue
to
be
our
message.
B
We
make
can
be
like
Revisited,
so
if
you
ever
revisit,
I
can
think
of
like
one
use
case.
This
is
something
which
helped
us
with
the.net
for
free
to
cut
as
well
so
people
when
they
want
to
migrate
from
like
they
have
a
legacy,
app
returning.net
3.1.
They
don't
intend
to
touch
it,
but
now
they
intend
to
upgrade
it
2.6.
B
Now,
at
this
point,
they
want
to
make
sure
that
things
are
still
working
and
the
usual
way
of
they
make
sure
things
are
still
working
is
by
adding
some
Telemetry,
and
at
that
point
they
will
be
blocked
from
using
open,
Telemetry
1.4
on
bits.
So
if
you
ever
support
it,
it
will
be
specifically
targeting
like
such
users
like
they'll,
say
that
hey
I
was
in.net.
3
and
I
have
stuck
there
and
I
created
2.6
and
open
Elementary
helped
me
with
that
migration.
B
So
this
was
a.
This
was
something
which
we
considered
for
DOT
net
452
support.
I.
Think
when
we
added
support
we
were
saying
is
we
are
going
to
indirectly
help
customers
migrate
from
old
version
of.net
to
the
new
one,
still
keeping
their
things
stable,
diversity
of
like
Telemetry.
Then
it's
a
good
publicity
thing,
we'll
get
a
lot
of
PRS
in
that
way,
so
yeah
something
to
keep
in
mind.
If
you
ever
revisit
this
decision
in
the
future.
C
C
B
E
Have
a
quick
topic,
something
related
to
talks;
okay,
regarding
the
reason.
B
A
B
Yeah
I
just
want
to
like,
like
we,
don't,
have
any
blockers
as
of
now
for
1.5,
so
we
are
still
proceeding
with
the
1.4
release.
This
Friday.
The
only
thing
painting
is
that
dogs
took
the
open,
Elementary,
dot,
IO
and
the
demo
project.
We
are
still
in
the
process
of
updating
to
the
newest,
but
I.
Don't
anticipate
any
issues.
B
Like
any
surprises,
then
that's
only
the
reason
why
we
would
hold
on
from
releasing
one
or
four,
but
that,
aside,
as
of
end
of
this
meeting,
we
are
still
proceeding
with
1.4
by
this
Friday,
just
something
to
put
in
the
meeting
notes,
as
we
can
right
now.
So.
F
Cj,
just
related
to
that
Martin
and
I
were
having
a
discussion
earlier
in
the
hotel.net
slack
Channel
I
I
saw
that
the
doc
person
I
think
he
was
working
with
like
commented
on
the
pr,
and
he
responded
like
the
changes
that
I
had
made
were
like
a
good
example.
E
B
Yeah
yeah
so
like
we
could
still
do
1.4
and
debate
about
whether
we
knew
the
we
do
the
static
one
or
the
a
thing.
Okay,
we
support
all
of
that,
so
that
should
not
block
1.5
yeah.
B
B
Yeah,
okay,
perfect
yeah
I
did
see
the
all
those
issues
in
as
long
as
it's
not
blocking
1.4
I'll
just
say:
okay,
we'll
just
close
my
eyes
temporarily.
B
Yeah
so
I
forgot
like
like.
Oh
sorry,
because
you
you
were
trying
to
say
something.
E
E
Let
me
share
my
screen
till
that
would
be
easier.
That's
okay,
foreign.
E
How
about
now?
Yes,
yes,
okay,
so
there's
some
something
called
like
the
named
options.
Support
that
the
the
support
that
was
added
in
1.4
and
I
was
just
trying
to
make
it
work,
but
for
some
reason,
I'm,
maybe
I'm
doing
something
wrong
that,
like
it's
just
not
working
so
basically
here's.
B
I,
don't
think
we
have
anything
to
understand
that
you
have
a
configuration
under
the
header
ASP
net
core.
You
have
to
provide
it.
I
mean
like
yeah
I
mean
someone
else
like.
Maybe
lnd
can
correct
me
so
go
to
your
app
settings.
I
don't
think
like
by
default.
Sorry,
you
had
app
settings.json,
oh
yeah.
Yes,.
E
B
C
G
B
E
It
yeah
so
I
think
I'm
I'm,
aware
of
this.
One
I
think
this
one
works
okay,
so
so,
basically
this
off
this
thing
doesn't
work.
It
doesn't
automatically
pick
it
up
from
the
options.
How
about
this
one?
There
is
a
named
option
thing:
it's
extension
method.
Does
this
do
anything.
G
So
what
you
can
do
is
what
you're
basically
doing
here
is
creating
like
an
eye
options
monitor
it's
all
hooked
up
to
this
magic
default
name,
which
is
string
dot
empty.
But
if
you
pass
a
name
here,
then
you
reference
that
name
you
can
control
which
options
instance
will
apply
to
that.
Builder,
probably
not
very
useful
for
instrumentation,
but
when
you're
doing
exporters
like
let's
say
you
have
two
providers
and
you're
exporting
some
traces
to
like
a
local
Jaeger
and
then
some
to
otlp
or
maybe
you're
doing
Jaeger
exporter
for
both
but
different
endpoints.
G
B
I
mean
basically
you're
saying
it's
not
a
thing
which
most
people
would
use.
It's
a
fairly
Advanced
scenario
where
you
have
multiple
options,
and
you
want
to
name
it.
So
you
can
identify
them
separately
in
usually
like
exporter
codes.
B
I
think
like
so
maybe
like
one
example,
would
be
beneficial
like
if
you
just
write
an
example
saying
hey
here
goes
one
example
where
you
can
use
named
options,
and
you
show
that
you
have
a
provider
where
you
add,
like
two
instances
of
Jager
the
first
one
binds
to
option
one
and
second
one
binds
to
option
into
another
option,
one
you
can
say
one
first
and
then
one
and
the
second
one
you
can
specify
something
else,
maybe
like
an
example
like
that
would
help
like
people
understand
like
what
it's
supposed
to
do
and
prevents
any
misunderstanding
or
confusion
that
it
will
like
magically,
read
app
settings.json
by
default.
B
Something
like
we
should.
You
are
basically
saying
like
by
doing
that
main
thing:
do
we
can
we
remove
line
35,
then
the.
E
E
Okay,
and
even
with
the
name
supplying
the
name,
we
still
need
to
have
935
right,
like
without
line
35
8.
This
just
this
alone
will
not
do
anything.
B
E
Okay
makes
sense:
okay,
yeah
I
think
that
that
helps
you,
because
I
I
think
yeah
I
was
just
in
an
impression
that
it
automatically
reads
it
from
the
app
settings.
So.
B
Like
just
create
an
issue
like
we
need
to
document
that
thing,
because
I
I
know
that
I
think
about
it.
There
is
a
potential
confusion
that
people
might
assume
that
35
is
not
required.
We
just
did
it
magically,
so
let's
make
it
clear
in
the
top.
We
do
not
do
that.
Okay,
so
if
we
can
open
an
issue
and
shut
yep,
okay.
C
I'm
just
gonna
say
side
note
about
the
named
options
for
instrumentation
like
I.
Can
I
can
make
an
argument
for
supporting
that
and
I
can
make
an
argument
for
not
supporting
that
I
think
where
it's
going
to
get
confusing.
Is
that,
unlike
exporters,
you
know
as
Blanche
described
where
you
might
have,
you
might
be
using
two
instances,
instances
of
an
exporter
and
be
exporting
with
different
configurations.
It
doesn't
really
work
for
instrumentation.
C
In
that
same
way
and
with
named
option,
it
kind
of
implies
that
you
could
configure
asp.net
core
like
instrumentation
twice
and
get
like
two
different
results.
But
I
guess
the
nice
thing
about
having
named
options
is
for
instrumentation
is
for
like
the
use
case
where
you
have
like
a
you,
have
a
single
configuration
file
which
might
have
like
a
production
and
maybe
a
staging
set
of
configurations,
and
so
you
know
based
off
of
like
environment.
C
You
pull
the
right
configuration
for
like
your
single
instance
of
ASP
net
core
instrumentation,
so
that's
kind
of
like
the
the
the
argument
for
but
I
think
it's
going
to
lead
to
confusion.
E
That
was
the
exact
reason.
Actually
even
I
was
trying
to
do,
because
if
customers
want
to
do
it
like
without
doing
any
code,
changes
just
let's
say
like,
for
example,
record
exception.
They
want
to
see
what
exceptions
they
are
getting
just
for
like
some
time,
it's
not
possible
to
do
any
without
that
without
the
like
doing
in
protein.
Just
so,
that's
the
exact
use
case.
I
was
trying
to
do.
B
That's
a
perfect
idea:
once
you
add
the
services
dot
configure
like,
then
it
will
pick
any
configuration
change
from
PI
configuration,
so
you
can
just
change
app
settings
and
don't
change
the
code
that
would
work
assuming
you
how
that
the
instrumentation
configure
options
to
read
from
the
right
eye
configuration
already.
B
A
C
F
F
B
C
But
actually
that
that
that's
the
use
case
that
I
think
is
going
to
lead
to
confusion.
So,
like
people
will
set
up
say
you
know
not
with
a
hosting
package
that
they'll
set
up.
Two
providers
and
they'll
want
to
configure
asp.net
core
instrumentation
for
one
provider
differently
than
the
other
provider,
and
that's
where.
B
F
C
B
Yeah
but.