►
From YouTube: 2023-01-04 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
A
B
C
F
A
C
I
A
A
A
I
E
A
So
yes,
the
first
thing
is
I
think
we
were
discussing
about
it
on
the
slack
Channel
as
well.
A
Yeah
I
mean:
should
we
like
I,
think
we
could
ask
the
dotnet
team.
We
have
a
weekly
sync
with
them.
There's
one
tomorrow,
but
I,
don't
know
if
that's
gonna
happen,
because
it's
still
like
early
in
the
start
of
the
year,
so
I
don't
know
if
people
are
back
from
vacation,
but
I
think
we
should
ask
them
and
like
maybe
just
have
this
thing
at
least
know
what
we
are
deciding
about
this
before
we
do.
The
final
stable
reviews,
foreign.
C
Yeah
I'd
be
interested
in
what
they
have
to
say.
I'm,
not
like
you
know,
holding
my
breath
that
they're
going
to
have
something
to
say:
that's
super,
you
know
fulfilling,
but
ultimately
I
don't
know
I,
don't
I,
don't
have
strong
opinions
here.
It's
just
I'm
continued
kind
of
I,
don't
know
I,
guess
frustration
over
the
lack
of
guidance,
I'd
just
be
a
little
wary
of
you
know,
given
that
we're
just
kind
of
going
through
the
motions
and
just
kind
of
following
following
step
with
with
Microsoft
I'd,
be
kind
of
wary
that
like
are.
C
We
ultimately
gonna,
create
problems
for
ourselves
down
the
line
and,
of
course
not
knowing
what
those
problems
could
be.
It's
not
like
I
can
you
know
give
you
any
concrete
concerns
on
that
front.
So
I
don't
know.
E
E
A
So
we
don't
see
any
issues
with
like
still
depending
on
the
5.0
version
like
there's
like.
Would
we
run
into
an
issue
where
some
something
is
feeling
because
of
the
old
package
and
then,
since
there's
no
support
for
it?
B
C
Yeah
I
think
that's
true
on
that
issue
that
I
shared
where
they
announced
this
new
practice.
They
they
seem
to
suggest
that
immediately
after
or
very
soon
after,
this
is
one
of
the
issues
lyric.
This.
C
D
C
G
C
Look
at
3.1.
No
sorry
stay
on
that
nougat
for
just
a
second
interesting
that
back
in
3.1,
they
had
a.
They
had
a
pattern
where
they
had.
You
know
three
one
zero
and
then
they
released
three
one
one
and
then
three
one
two
and
then
so
on.
They
had
a
bunch
of
versions
for
3.1,
but
then,
if
we
scroll
up
and
look
at
5.0
really
so
besides
the
preview
versions,
there
was
just
one
500
version:
it's
not
like.
They
then
later
released
like
a
five,
oh
one
or
something
like
that.
C
F
C
C
That
would
be,
if
that's
the
case,
though,
if
they
do
end
up
having
these
like
minor
releases
and
they
ultimately
deprecate
like
like
6.0.0.
That
could
be
I.
Think
a
little
Annoying
in
my
opinion,
then
we're
just
kind
of
like
chasing
it
and
we're
just
constantly
just
upgrading
just
because
they.
E
C
Shared
with
us
today
in
the
slack
channel
was
the
pr
for
craft
ql.
I,
don't
know
if
you,
if
you've
looked
at
that
at
all
I
just
kind
of
skimmed
through
it
I
didn't
look
at
it
pretty
very
closely,
but.
A
C
This
up
there's
actually
a
comment
so
about
net
five,
some
like
directive.
If
you
scroll
down
through
the
comments,
a
little
ways
I
forget
who
raised
it,
might
have
been
Robert.
F
C
C
C
It's
no
longer
supported
blah
blah
blah,
and
then
you
know
the
Shane
32
guy
basically
says
well
generally
like
this
is
this
is
the
the
type
of
thing
that
I've
heard
from
like.net
people
for
Library
authors
for
years
is
like
this?
Is
this
kind
of
I
don't
know
that
this
is
actually
documented
as
a
best
practice,
but
I
speak
to
so
many
Library
authors,
and
this
is
just
kind
of
like
the
understood.
E
C
We
just
keep
support
for
it
now
that
may
be
changing.
You
know,
that's
why
I'm
really
interested
in
like
the.net
team's
guidance.
You
know
like
as
the
ecosystem
changes
like,
given
that
this
is
how
Library
authors
think
today.
If
they
need
to
think
differently
tomorrow,
it
would
really
go
a
long
ways
if
Microsoft
had
a
statement
about
that.
D
D
Always
been
safe
to
do,
but
the
runtime
team
is
changing.
What
they're
doing
right,
we're
seeing
them
introduce
build
warnings,
we're
seeing
them
deprecating
stuff,
so
I
think
they're
kind
of
changing
the
standard
that
we
all
live
with,
which
was
like
you
could
support
it
forever,
because
there
was
no
reason
to
remove
it
like
it
just
worked,
but
now
there's
actually
stuff
being
removed
from
the
newer
libraries.
So
users
can
take
a
package
that
no
longer
has
platform
specific
code
right.
That
was
the
reasoning
we
got
from
runtime.
G
D
C
C
I'd
still
err
on
the
side
of
caution
and
say
like
until
we
have
like
a
a
thing
where,
like
we
really
do,
need
to
upgrade
because
we're
going
to
use
a
new
API,
that's
been
introduced
in
a
newer
version
or
something
like
that
that
we
go
as
long
as
we
can
go
are
as
low
as
we
can
go
with
the
version.
But.
D
This
one
in
contribute
have
felt
some
pain.
Trying
to
keep
that
thing.
Building
I
forget
what
I
was
doing.
All
the
3.1
CI
jobs
were
failing,
so
I
had
to
go
in
I
wanted
to
get
it
all
passing,
and
it
was
significant
effort
to
support
everything.
That's
going
on
in
that
repo,
because
you
have
some
projects
that
are
still
allowing
2.13.1.
Whatever
there
was
an
issue
with
mock,
some
of
the
tests
were
failing.
I
have
no
idea.
D
Why
just
bumping
the
version
of
not
fixed
it,
but
the
latest
version
doesn't
have
targets
for
some
of
the
older
stuff,
so
I
had
to
do
some
hacks
for
that
I
think.
Eventually,
we
will
run
into
issues
where,
like
the
images
that
we
use
in
CI,
just
no
longer
exists,
they'll
just
be
removed
from
like
the
Microsoft,
whatever
repo
that
the
images
live
in
I.
Think
at
some
point,
we'll
just
have
to
remove
it
to
keep
things
building,
but
so
what
I
was?
Supposing
we
do
here
is
put
a
policy
into
contrib.
D
That
says,
whatever
our
support
policy
is
going
to
be
like,
if
you're
a
maintainer
of
some
code
or
contrib,
then
you
must
only
ship
supported
run
times.
You
don't
have
to
deprecate
anything,
but
I
was
going
to
say
that,
like
anything
new,
you
release
you're
not
allowed
to
keep
the
targets
for
anything,
not
supported
just
to
allow
us
as
maintainers
to
be
able
to
go
in
and
like
remove
three
down
one
or
remove
5.0
right
now
we're
getting
pushed
back
like
this
comment.
D
C
A
C
See
yeah,
that
is
all
annoying
I,
agree.
Clear
policy
here.
A
I
A
I
think
all
the
new
projects
that
come
in
it
would
be
good
if
we
could
enforce
them
to
use
the
supported
at
times
only
right
for
existing
projects,
which
are
trying
to
run
stuff
on
older
Frameworks
I
feel
we
should
be
able
to
get
rid
of
that
like
they
can
still
run
their
project
on
net
6.0
and
7.0.
So
they
have
some
level
of
assurance
that
it
works,
at
least
on
the
newer
Frameworks,
but
I
mean
like
what's
the
end
game
here
like
at
what
point?
Do
we
remove
net
code
app
3.1
until
we'll.
B
F
C
D
So
what
I
want
to
do
is
clear:
the
runway
for
us
to
be
able
to
go
in
and
just
replace
that
with
four
six
two
and
then,
if
anyone
complains,
we
would
just
have
a
policy
in
there
that
we
all
agreed
on
and
say
like
hey.
This
is
the
policy
it
needs
to
be
updated.
If
users
want
to
continue
to
use
four
five
two,
the
package
will
still
be
out
there
on
nougat.
They
can
still
use
the
older
package.
They
just
won't
be
able
to
take
updates.
A
D
H
D
Was
thinking
about
doing
is
opening
a
PR
that
adds
a
section
in
here
that
says
like
the
open,
Telemetry,
contrib,
repo
Target
framework
support
policy
and
the
policy
will
just
be.
We
only
support,
Frameworks
or
runtimes
that
are
supported
by
Microsoft
and
then
I'll
have
some
verbiage
in
there.
That
says,
like
anything,
that's
already
released
can
stay
up
there.
You
don't
have
to
take
anything
down,
but
any
new
release
out
of
the
repo
must
only
support
supported,
run
times,
which
is
basically
a
long
way
of
saying
like
we
won't
be
able
to.
F
D
What
I
was
going
to
do
is
I
was
going
to
open
that
as
a
PR
with
that
text
in
this
file
or
some
other
file,
and
then
just
tag
all
of
the
code
owners
that
we
have
and
contribute
today
and
let
anybody
voice
any
concern
and
see
if
we
can
get
consensus
like
I,
think
everybody
should
buy
into
it
and
then
once
it's
there,
we
can
enforce
it.
I
don't
want
to
just
like
throw
it
in
I
know
we'll
get
pushback
from
some
groups,
but
if
there's
enough
consensus,
maybe
we
can
get
it
in.
A
That
that
sounds
good
to
me,
but
like
what
do
we
do
about
the
test
projects
like
the
CI
workflows
that
we
still
have
to
run
for
the
unsupported
run
times.
D
C
There's
the
maintenance
portion
of
this
and
the
you
know:
what
has
the
package
actually
Target
and
then
there's?
What
do
we
actually
test
and
I
think
that
that's
more
speaks
to,
like
maybe
a
support
statement
kind
of
across
the
board
for
all
of
our
instrumentation,
which
would
be
something
like
hey.
You
know
if
we
have
instrumentation
that
targets
like
net
standard
2o,
for
example,
which
theoretically
should
work
on
that
chord,
app
3.1
just.
G
C
That
hey
by
the
way,
we're
not
testing
that
we
have
no
idea
using
your
own
risk
type
of
thing
and
so
I
think
it's
okay,
I
guess,
in
my
opinion,
that
we
don't
have
automated
tests.
E
A
So
what
we're
essentially
saying
is
for
the
existing
projects
that
are
referencing
older,
unsupported
runtimes.
We
are
not
going
to
change
that,
but
the
test
projects
for
them.
We
will
change
the
runtimes
that
the
test
would
be
run
on
even
for
the
existing
projects.
We
would.
We
would
update
the
Target
framework
of
the
test.
D
What
I'd
really
like
to
do
is
have
like
a
variable
or
two
variables
in
the
props
files.
They
might
already
be
their
like
minimum
supported.net
framework
version,
minimum
supported
core
app
version
and
then
use
those
and
all
the
project
files
and
then
have
it
just
standardize
across
the
board.
If
you're
targeting.net
framework,
your
462
and
your
test
will
run
against
462,
maybe
we
do
some
newer
ones
predominant
core.
Your
minimum
is
six
and
we
run
the
test
against
six
and
seven.
D
A
F
A
F
C
I
think
another
part
of
the
policy,
and
it
is
you
know,
yeah.
We
could
have
like,
like
minimum
supported.net
framework,
minimum
supported.net
core,
but
I
think
we
should
also
have
minimum
supported
net
standard
in
general,
the
the
instrumentation
projects
in
the
core
repository
have
I
think
at
a
minimum
of
462
and
a
net
standard
2-0
build
just
like
the
SDK
and
the
API.
C
G
C
C
D
I
think
that's
still
in
line
with
what
I'm
proposing,
because
we
kind
of
already
have
done
this
in
the
main
repo.
We
just
only
support,
supported
things
and
we've
put
back
that
standard
everywhere.
So
I
really
just
want
to
do
the
same
and
contribute
there's
just
more
more
people
involved,
so
I
want
to
codify
it.
First
yeah.
G
D
G
H
A
Existing
ones
we
have
existing
projects
that
have
already
made
it
to
the
content
report
we
are
going
to.
Let
them
continue
to
support
whatever
old
runtime.
They
want
to
support
right
so
like
if
they
are
supporting
net452
like
in
this
case.
We
are
not
going
to
change
the
source
project
because
I
mean
like.
Are
we
going
to
change
this
as
well?
Like?
Let's
say
this,
the.
A
F
A
C
D
A
I,
don't
think
we
don't
have
any
CIS
running
for
four
five,
two
as
far
as
I.
Nobody
can
quickly
let
go.
A
A
A
C
G
G
C
The
agenda
notes
based
off
of
this
conversation,
to
see,
if,
like
this
kind
of
encapsulates
the
things
that
we've
said
where
the
policy.
B
D
We
comfortable
not
running
tests
and
it's
kind
of
scary,
if
you
like
shipping
code
from
an
open,
Telemetry
repo,
doesn't
do
anything
other
than
stamp
it
as
like
official.
So
it's
basically
saying
like
this
is
an
official
Library.
That's
run
through
like
the
official
whatever,
but
if
we're
not
actually
doing
anything,
it's
kind
of
scary,
we
might
be
misleading
a
little
bit.
A
D
A
D
C
G
D
D
D
D
It
will
go
in
and
then
a
couple
weeks
later,
I'll
get
like
a
runtime
team
member,
commenting
that
some
perf
tests
fail,
but
there
was
some
regression
and
something
else,
so
they
definitely
have
like
different
Gates
that
the
code
is
passing
through
as
it
like.
It's
closer
to
release,
I'm,
not
saying
we
need
to
go
to
that
level,
but
it's
it's
something
that
we
could
do
if
we
needed
to.
F
A
C
I
mean,
as
we
go
into
the
future
here,
like
our
net
standard
20
targets,
just
aren't
going
to
be
tested
by
really
anything
at
all,
I
mean
because
right
most
of
our
tests,
if
they
don't
already
they're
only
going
to
be,
you
know,
targeting
like
net
6.0
or
or
whatever,
and
if
there's
any
package
that
has
net
6.0
Target
or
something
other
than
that
standard,
then
the
net
standard,
20
Target
of
that
package
goes
completely
untested.
D
D
So
in
contribute
the
moment
see
how
there's
core
three
at
three
one:
that's
what
I
was
putting
back,
so
we
at
least
run
on
all
those
dot
net
core
runtimes,
but
see
the.net
framework
on
time,
so
that
452
project
is
only
ever
going
to
run
against
four
six.
Two,
not
gonna,
run
against
four
five:
five,
two
four
five
one:
four
dot,
eight
4.8.1,
so
we're
being
very
minimal
on
our
dotnet
framework
side.
D
So
what
these
things
are
here
is
the
basically
the
SDK
version,
so
the
Net
7
SDK
has
the
ability
to
run
older
Frameworks.
It's
like
backwards.
Compatible,
am
I
correcting
that.
C
A
G
H
C
A
A
F
A
Think
that's
a
good
question
as
well.
I
feel
like
I,
don't
know,
I
mean
if
our
purpose
is,
if
our,
if
what
we
offer
them,
is
just
a
way
to
host
their
code
in
like
ship
packages
but
like
what
is
our?
What
do
we
offer
exactly
like?
Are
we
offering
that
we
will
host
your
code
and
we'll
also
test
it
on
all
supported
or
all
the
desired
runtime
Frameworks
that
you
want
us
to
test
it
on?
C
E
D
E
D
I
do
think
that
the
question
of
what
are
we
providing
should
really
just
be
like
safety
and
comfort.
Users
should
be
able
to
see
these
packages
and
I
mean
they're,
probably
already
assuming
anything
with
open
Telemetry
and
it
has
the
same
guarantees
and
the
main
repo
there's
very
tight
guarantees.
We're
very
guarded.
D
We
have,
you
know
very
limited
in
what
we're
supporting
contributes,
gets
completely
different,
it's
kind
of
the
wild
west,
but
you
don't
really
know
looking
at
a
package
anymore,
because
we
removed
contrib
right
you're,
just
looking
at
open
Telemetry
packages
and
you're,
probably
getting
warm
happy
fuzzies
like
okay.
All
of
these
are
the
same
quality
and
I.
Don't
know
if
that's
completely
true,
they're,
relatively
safe
right,
like
I,
wouldn't
expect
our
net
462
tests
to
fail.
D
If
we
suddenly
made
it
four
eight
or
four
five,
two
I
I
trust
the
runtime
team
they're
doing
a
really
good
job,
but
we
can't
say
with
authority
that,
like
that
four
five
two
package
has
been
tested
on
all
of
the
on
that
framework
run
times,
it
can
actually
be
executed
on.
So
we
should
probably
either
document
it
or
make
it
more
narrow
so
that
we
can
actually
tell
people
what
we're
doing
that
makes
sense.
I
was
kind
of
rambly.
A
C
C
You
know
hey
if
your
package
is,
if,
if
you
follow
within
these
rules,
as
far
as
like
the
targets
that
your
package
has
chosen,
then
it
will
successfully
be
tested
in
this
way.
But
you
know
if
we,
if
we
just
let
people
if
we
don't
apply
any
control
over
what
their
packages
can
Target
that's
possible
right.
That,
like
there
will
come
a
day
where,
like
some
test,
Suite
doesn't
run
at
all
or
like
work
against
that
package
at
all.
Unless
these
two
things
are
somewhat
coordinative.
D
I
D
Into
the
CI
Matrix
and
added
452,
when
that
executes,
it's
either
going
to
fail,
or
it's
going
to
emit
a
warning
saying
like
hey.
This
image
is
not
supported
and
it's
going
to
be
removed
in
the
near
future.
So
that's
the
risk.
If
we
allow
these
packages
to
use
these
older,
unsupported
runtimes,
it
will
come
a
point
where
we
can't
test
them,
because
GitHub
just
doesn't
have
images
for
some
of
these
really
old,
unsupported
things
and
that's
when
it
will
become
a
real
problem.
D
D
D
G
C
C
D
C
Sure
and
that's
the
reason
why
net
standard
is
so
problematic
and
and
and
testing
is
a
big
is
a
big
point
of
that
Andrew
Luck,
guys
blog
post,
which
is
like
yeah,
so
you're
claiming
support
for
net
standard
2-0.
But
are
you
actually
testing
it?
You
know
and
in
a
lot
of
cases,
I
think
the
answer
is
no
for
some
Library
authors,
you
know,
the.net
team
is
maybe
in
like
an
exception
because
they
have
so
much
so
many
hands
to
be
able
to
manage
significant
test
infrastructure.
C
B
D
Where
Do
We
Go
From
Here.
You
guys
want
me
to
try
to
draft
some
kind
of
support
thing.
A
D
H
F
B
I
D
Es
that
one's
about
dependency,
injection.
C
G
C
B
D
D
Basically,
just
working
with
these
different
folks
there's
some
kind
of
Behavioral
differences
in
1.4.
D
You
could
call
them
breaking
changes,
they're,
definitely
behavioral
changes
but
they're,
pretty
scoped
to
like
the
configure,
Builder
API,
so
I
don't
think
their
release.
Blockers
but
I'm
replying
on
here,
I,
probably
sound,
very
authoritative
from
like
the
maintainers,
but
you
guys
should
have
a
voice
in
here
too.
You
might
want
to
give
it
a
read
through
and
if
you
disagree,
we
can
try
to
come
up
with
a
plan
or
pull
stuff
out.
A
C
D
it
calls
into
configure
services.
So
what
it's
doing
here
is
it's
registering
options
and
eye
configuration
and
making
sure
that
everything
is
hooked
up
with
the
same
features
across
the
board.
So
you
get
like
named
options.
If
you
register
a
delegate,
it
participates
in
options
in
this
code
and
externally.
So
if
you
ever
have
like
a
class-
and
you
inject,
I
options
otlp
Explorer
options.
All
those
things
are
going
to
fire.
It's
just
going
to
work
kind
of
consistently
across
the
board,
with
named
option
support
with
support
for
pulling
environment
variables
out
of
eye
configuration.
D
There's
all
these
features
kind
of
tied
into
this
block
of
code.
In
order
to
make
that
work,
it
has
to
call
configure
Services
here,
which
means
you
need
the
service
collection
so
for
users
that
were
previously
calling
this
in
configure
Builder.
So
remember:
there's
these
like
there's
this
tune
phase
thing
the
first
phase.
You
have
your
service
collection,
the
second
phase
service
provider
has
been
created.
You
can
no
longer
add
services.
D
D
C
It'll
remind
me
that
this,
the
the
configure
Builder
API,
that
people
are
using
that
was
previously
offered
by
the
hosting
package
right.
D
D
C
D
D
D
D
Which
is
kind
of
universal?
Basically,
all
of
these
extensions
that
we
have
like
add
Zipkin
and
Jaeger
and
otlp
and
Prometheus
those
are
really
not
safe
to
be
called
in
configure
Builder
configure
Builder
is
really
for
like
doing
what
line
78
is
doing,
which
is
your
service
provider
is
complete.
Now
you
want
to
get
some
options,
get
some
dependencies
new,
something
up
and
add
that,
as
like
a
processor
foreign.
A
D
C
D
D
Little
bit
I
think
he
has
the
original
code
right
here.
So
what
he's
basically
trying
to
do
is
just
make
it
figurable.
He
wants
to
only
turn
on
the
otlp
exporter
based
on
configuration.
If
you
look
at
our
examples,
we
have
the
code
with
how
how
you
can
make
that
work.
So
this
is
kind
of
this
is
not
a
valid
use
case
for
configure
Builder
as
I
intended
it
to
be
used.
So
it's
an
easy
workaround,
but
this
code
worked
before
and
now
it
doesn't.
So
it's
I
understand
that
their
argument
that
we
broke
something.
D
So
the
only
reason
here
that
this
that
block
is
nested
inside
a
configure
Builder
call
is
the
user
wanted
to
access
eye
configuration,
but
you
don't
need
to
do
configure
Builder
to
use
eye
configuration
like.
If
you
look
at
our
example
code,
we
do
that
just
off
the
host.
We
just
get
it
off
the
app
builder.
A
C
C
D
I
forgot
to
mention
that
in
my
latest
reply,
I
was
going
to
say
technically
most
of
this
stuff
was
never
shipped
as
stable,
so
we
are
allowed
to
change
it.
But
that's
I
don't
like
to
say
that
either
because,
like
sure
we
have
that
right,
but
it's
still
not
great
for
users
when
you
exercise
that
right
and
break
their
code.
C
Yeah
I
mean
I
agree,
it
doesn't
feel
great
to
say
it,
but
at
the
end
of
the
day
you
know
there
there
were
reasons
that
we
took
we've
taken
so
long
to
release
a
stable
hosting
package.
I
mean
I.
Think
at
this
point
all
we
can
say
is
sorry.
It
took
us
so
long
through
and
then
maybe
we
broke
you
along
the
way.
I
D
D
C
D
When
we
were
kind
of
looking
at
that
extension
before
I
was
saying
like
why,
why
does
it
now
have
the
dependency
in
this
service
collection
and
it
was
for
those
features
around
options
and
environment
variables?
D
So
the
question
is
really
like:
how
compelling
are
those
things
I
think
they're
compelling
I
think
they're
more
useful
than
calling
configure
Builder
the
way
this
user
did
I
think
generally
being
able
to
have
named
options
and
do
the
environment
variables.
Those
were
also
things
that
other
users
asked
for.
That
I
think
are
useful,
so
it
it's
sort
of
we're
going
to
make
some
users
map
we're
going
to
make
some
users
happy.
We
just
have
to
decide
like
what
is
our
long-term
goal.
D
D
It
does
and
that's
how
it's
throwing
the
not
supported,
expect
exception.
Basically,
the
the
provider
Builder
understands
what
phase
it
is
in.
That's
the
new
change
before
it
didn't
really
it
just
tried
to
do
it
and
if
it
failed,
it
would
just
beat
that
exception.
Now
it
has
better
awareness.
So
if
you
try
to
do
something
you
can't
it
throws
an
exception
and
it
gives
you
a
message
of
like
hey.
You
can't
add
a
service
after
blah
blah
blah
so
that
that's
the
kind
of
changes
I
made
it
smarter
and
proved
it.
D
D
D
And
it
shouldn't
impact
most
users,
I
mean
that's
just
my
gut
I.
Don't
have
any
data
behind
that,
but
I
feel
like
most
people
are
probably
doing
more
standard
startup
they're,
not
calling
configure
Builder.
The
only
reason
you
would
ever
call
configure
Builders.
If
you
were
trying
to
do
something
really
advanced.
D
D
C
G
B
G
A
Sure
I
have
some
time
I
mean
I.
Can
I
have
like
if
everyone's
okay
with
it.
A
A
A
Yeah
and
I
also
think
like.
Maybe
we
can
have
1.4.0
released
as
it
as
things
are
right
now.
Maybe
we
can
have
a
1.5
version
later
on,
where
we
remove
it,
but
yeah
I
think
we
first
need
to
know
if
like
if,
if
this
is
discouraged
or
encouraged
by
the.net
team,
we.
A
If
it's
gonna
happen
blast,
but
maybe
we
could
bring
more
and
tomorrow's
sync.
D
Time
does,
is
you
know,
after
a
major
release,
they
just
go
in
and
like
update
the
targets
across
the
board
and
then
all
packages
just
cut
over.
So
like
all
the
Microsoft
extension
packages
will
be
net
8
and
they
will
all
reference.net8
there's
never
like
referencing
an
older
one.
So
it's
in
their
case
I
think
it's
simpler.
They
just
kick
everything
to
the
next
version
and
drop
support
for
anything.
That's
less
support.
B
D
D
C
A
Yeah
with
that
one
I
think
the
yeah,
the
only
question
I
had
was
like
if
we
because
extension
logging
packages
in
the
3.1
version
of
those
packages
are
still
supported,
they're,
not
deprecated,
yet
so
in.
We
would
be
forcing
users
to
move
to
six
right
if
we
are
consistently
pumping
all
the
extensions
packages.
26.0
yeah
yeah
I
mean
like
I,
don't
know
if
we'll
have
users
complaining
saying
they
have
some
other
third
package,
third
party
library
that
they're
using
which
will
only
work
on
3.1,
and
it
was
working
fine
until
now
like.
C
C
G
A
Like
today,
there
are
noble
warnings.
What
I'm,
like
trying
to
know
is,
do
we
have
to
worry
about
like?
Are
we
sure
that
at
least
for
untilnet.net
8.0
release
we
don't
have
to?
If
there
are
no
warnings
being
shown
thrown
today,
then
they
won't
the
build
120
warnings
up
until
8.8
Knight
88.0,
at
least.
B
F
C
Because
if
that
were
the
plan
right
like
that
would
be
a
that
would
be
a
stronger
statement
in
my
mind
from
them
saying
like
you
know,
we
really
are
trying
to
like
move
people
along.
You
know.
F
D
D
You
know,
XYZ,
those
are
usually
security,
things
I,
don't
know
if
anyone
would
complain
just
because
some
random
package
is
marked
as
deprecated,
but
it
doesn't
seem
that
unreasonable
for
me
for,
like
some
Enterprise
team,
to
have
the
rules
that,
like
you,
may
not
use
a
dependency,
that's
marked
deprecated
and
they
have
some
tool.
That's
verifying
that,
and
you
know
they
wouldn't
be
able
to
use
open
Telemetry,
because
it's
using
options
which
is
marked
as
deprecated.
Who
knows
no.
C
That
makes
sense
like
improve
the
tooling
around
this,
enabling
people
to
to
stay
current
if,
if
they,
if
that's
what
they
want
to
do
so
again,
more
of
an
end
user
problem
than
like
Library
authors.
Taking
like
this
strong
stance
of
restricting
what
their
Library
support.
B
D
A
E
A
Yeah,
so
we
had
some
internal
customers
asking
about
support
for
exponential
histogram,
but
even
if
open
Telemetry
SDK
offers
that
support,
it
would
take
some
time
for
us
to
like
update
our
exporter,
like
proprietary
Microsoft's,
proprietary
exporter
and
the
back
end
to
support
these.
It
will
still
take
some
time
so
there's
no
like
pressing
need
for
it
right
now,
but
yeah
definitely
I
mean
I.
Think
people
would
expect
it
sometime
in
this
year,
like
they
would
expect
the
support
for
exponential
histograms
yeah.
C
So
there's
a
spec
issue
open.
It's
been
open
for
a
few
weeks
that,
basically
all
it
is,
is
that
it,
my
colleague
Jack,
has
submitted
it.
It
just
marks.
Exponential
histograms
is
stable.
It's
not.
G
E
C
Like
I
know,
Riley
and
sijo
are
both
pretty
big
voices
and
improving
metric
spec.
So
when
they're
back
I
mean
I,
think
that
I
think
that's
kind
of
what
that
specification.
Pr
is
waiting
on.
C
F
C
G
F
G
C
Imminent,
like
basically
like
I'm,
assuming
I'm,
assuming
like
Riley
and
CJ,
would
probably
thumbs
up
this,
but
I
think
that's
kind
of
what
it's
waiting
on
a
few
more
actual
metric
approver
voices
giving
their
thumbs
up.
C
Because
this
is
important,
because
there
are
definitely
like
some
public
API
changes
right,
that
we
would
need
to
ship
and
we
wouldn't
want
to
Forge
forth
with
exponential
histogram
stuff
when
we
are
still
kind
of
waiting
for
1.4.0
to
release.
So
if
we
still
think
that's
like
a
number
of
weeks
out
or
like-
maybe
not
until
the
end
of
this
month,
then
it
could
be
reasonable.
C
E
C
But
this
this
branch
is
functional,
as
is
there's
probably
a
lot
to
discuss
about.
Like
you
know,
no
there's
definitely
like
some
performance
things
to
tune
here
and
then
also
just
the
public.
Api
may
not
be
quite
what
we
want
to
expose.
F
C
If
we
wanted
to
kind
of
like
move
things
along
or
try
to
move
things
along
in
the
interim
I
kind
of
proposed,
like
a
a
method
of
splitting,
this
PR
up,
I
haven't
studied
things
closely
enough
to
figure
out.
If,
if
this
works
but
I
think
that
there's
a
number
of
things
from
this
PR
that
I
could
ship
without
exposing
public
API.
C
That
would
at
least
allow
us
to
just
land
a
little
bit
more
on
top
of
Riley's
original
work
and
just
kind
of
keep
moving,
namely
that
first
point
which
is
like
Riley
dealt
with
like
all
like
the
the
aggregation
of
stuff.
But
then
it's
just
not
wired
through
to
like
the
metric
point
class,
which
is
I,
think
the
main
thing
and
I.
F
C
I
can
do
that
without
touching
the
public
API.
F
A
F
E
A
Definitely
push
those
changes
and,
and
also
since
they're,
very
like
exclusive
and
not
really
touching
any
of
the
hot
parts
for
other
metric
types.
C
C
Work
on
that
a
little
bit
this
week,
it
I
am
pretty
excited
about
this
work.
I
mean
we
definitely
have
customers
in
your
Relic
that
won't
want
this
exponential
histograms
are
nice,
it's
nice
not
to
have
to
like
try
to
guess
at
the
appropriate
histogram
bounds.
C
A
Cool
I
mean
I
I,
like
I,
don't
know
if
I
think
we
can
I.
Let's
wait
for
CJ
to
be
back
as
well.
He
come
he's
coming
next
week
and
we
can
see
like
even
we
could
probably
consider
putting
this
in
1.4.0
as
well.
If
you
feel
confident
about
it
like
even
with
the
public
API
changes,
if
we
really
want,
but
I
think
we
have
a
lot
of
public
API
changes
already,
but
for
like
for
1.4.
release.
C
That
I
would
yeah
if
we
think
I
mean,
especially
if,
like
you
know,
I'm
not
strong
I'm
I'm
I
like
the
spec
could
stabilize
soon,
but
even
then
I'm,
not
like
superb
of
the
super
strong
opinion
that
this
should
ship
with
140,
especially
if,
like
you
know,
we're
pretty
confident
that
we
can
ship
one
5-0.
You
know
some
way
shortly
afterwards.
You
know
February
or
March
at
the
latest,
maybe
and.
D
C
And
also
we
have
a
number
of
other
metrics
related
improvements
that
that
are
still
slated,
probably
post,
140
I
know
see.
Joe
was
dusting
off
the
work
for
exemplars,
for
example,
right.
F
A
F
C
F
F
A
A
A
Okay,
so
yeah,
that
was
this
issue
that
was
created
when
creating
multiple
Hotel
tracing
pipelines.
Each
of
them
subscribes
to
the
sources
and
exports
activities.
So
this
is
essentially
what
they're
doing
is
they
have
a
asp.net
core
web
application
project?
Let
me
see
if
I
can
just
show
it
real.
A
Yeah
so
they
have
a
asp.net
core
web
application
project
where
they
set
up
the
hotel
SDK,
but
then
they
have
a
test
project
which
references.
The
I
don't
know.
If
this
ZIP
thing
would
work.
A
H
I
C
A
Ascnet
application
in
the
startup
there's
one
SDK
registration
for
traces.
They
have
added
ASP
net
core
instrumentation,
and
then
they
have
a
test
project
which
is
referencing
that
that
asp.net
application
and
has
three
different
classes
with,
and
they
all
have
their
own
set
of
tests
and
they
all
have
a
class
fixture
in
X
unit
where
they're
sharing
like
they
create
a
web,
app
use
a
web
application
Factory
and
provide
the
program
file
of
the
ASP
and
it
actually
asp.net
application.
A
A
The
tests,
the
the
way
the
test
is
they're
asserting
the
number
of
times
something
was
added,
and
it's
not
matching
up
when
they
run
it
all,
because
by
default
tests
are
tests
from
different
classes
are
run
in
parallel
when
they
run
individual
tests
it
passes.
All
of
that
is
works
out.
Checks
out,
so
listening
to
activities
should
be
done
once
per
process,
and
it
should
be
possible
to
run
integration.
That
was
the
expectation
that
they
had.
F
A
She
this
person
is
also
at
Microsoft,
so
yeah
kind
of
quoted
me
out
of
context
here,
saying
you're,
saying
users
can
only
run
integration
tests
sequently,
which
is
not
a
good
design.
So
I
didn't
say
that,
like
she
left
omitted
this
part
out,
but.
C
A
Yeah
so
I,
what
I
found
was.
Let
me
quickly
do
that.
One
thing:
okay,
I
know
what
to
do
now.
So
there.
I
A
Asp.Net
core
web
application
and
in
the
program.cs
they
set
up
the
tracing,
SDK
and
rdsp
net
core
instrumentation.
Then
they
have
a
test
project
which
references
this
and
they
do
this
web
application
Factory
and
provide
the
program
of
the
the
program
class
of
the
asp.net
core
app
and
they
have
three
different
test
classes.
Each
of
them
uses
this
x
unit
feature
iclass
fixture,
so
they
each
test
class
gets
its
own
in
memory
posted
a
web
application.
F
H
A
I
think
it's
all
one
process
because
yeah,
but
then
there
are
three:
what
is
going
on
in
my
machine.
I
A
Are
three
like
instances
of
the
SDK,
because
these
tests
are
being
run
in
parallel
by
default?
They'll
run
in
parallel
until
we
have
an
X
unit
configuration
which
says
no
to
that.
But
I
was
wondering
if
there's
anything
that
we
need
to
do
here
so
like.
If
I
run
these
tests
and
okay.
A
Yeah,
so
they
all
fail
if
I
run
them
together,
because
they're
running
parallely
and
they're
like
expecting
the
counts
to
match
which
don't
because
the
expected
count
was
300.,
but
they
actually
get
900,
because
there
are
three
sdks
instances,
because
each
of
these
classes,
each
of
these
test
class,
is
going
to
create
on
so,
and
they
said
they
cannot
use
different
activity
sources
because
they
are
trying
to
test
the
consumer's
application.
They
don't
have
any
control
over
changing
like
the
sources
here
or
like
having
multiple
sdks
with
different
activity
sources
and
also
I.
A
A
Like
before
they
make
that
call
to
the
asp.net
application,
they
can
add
a
Trace
State
with
the
name
of
the
class
and
then
when
they
are
doing
the
assertion
they
can
just
check
and
then
making
the.
When
they're
doing
the
assertions
on
the
count
checks,
they
can
check
only
for
the
activities
which
are
the
Stray
state,
so
that
will
run
fine,
but
I
don't
know
if
that's
the
best
thing
to
do
or
like.
If
what
kind
of
guidance
we
should
provide
sorry,
this
is
this
was
not
a
quick
question.
D
A
G
A
C
Because,
like
in
a
different
language,
this
would
all
be
different,
like
I,
think
that
in
in
a
different
language,
if
there
were
multiple
Tracer
sdks,
which
is
possible,
then
you
know
you'd
get
a
tracer
provider
and
any
given
piece
of
instrumentation
would
only
you
know:
you'd,
probably
like
di
that
Tracer
provider
into
the
instrumentation
library
or
something
you
know,
but
it
would
only
that
instrumentation
would
only
invoke
that
one
Tracer
provider,
but
in
our
world,
where
we're
like
it's
more
like
an
event
based
thing
where
like
activities
are
happening
and
we
have
a
listener.
C
That's
that
subscribes
to
things.
We
have
less
control
over
how
things
get
invoked
and
from
where
it's
just
a
different
architecture.
D
I
had
this
there's
this
issue
in
my
on-call
pew,
that
is,
some
customer
has
open
Telemetry
and
an
application
insights
in
the
same
process,
so
they're
both
listening
to
activities
in
the
same
problem,
open
Telemetry
is
sampling,
which
causes
app
insights,
to
collect
an
activity
and
Export
it,
and
it's
same
idea.
It's
kind
of
a.net
thing
where
it's
it's
just
one
instance
of
activity
being
handed
to
both
so
I,
don't
know
what
we
could
do
there.
A
A
A
If
everything
is
identical,
like
you
know
what
what
the
action
on
activity
started,
the
action
to
be
executed
on
activity
stock
should
listen
to
and
if
all
of
those,
if
you
already
have
an
existing
activity
listener
in
memory
with
the
same
set
of
actions
and
stuff,
what
we
don't
want
to
pay
I,
don't
know
if
we
won't
do
it.
E
A
D
D
A
D
D
That's
totally
valid
I
was
just
trying
to
think
of
other,
so
that
factory
dot
create
client
call
line
12..
If
you
put
a
break
point
on
line
12,
and
then
you
looked
at
the
three
different
clients,
my
guess
would
be.
They
have
different
hosts,
so
they're
all
sending
to
different
ports,
I
would
assume,
but
it
maybe
not
I'd
have
to
kind
of
see,
because
if
it's
Kestrel
Kestrel
can't
Port
share
like
IIs
can.
D
So,
even
though
it's
one
process,
it's
got
three
hosts.
It's
got
to
have
three
different
sockets
that
it's
listening
on,
so
each
one
should
have
a
unique
Port
which
you
could
possibly
detect
and
then
filter.
So
maybe
you
can
make
it
work.
It
wouldn't
be
very
elegant
or
clean,
but
it's
I
think
possible.
A
A
D
A
I
D
A
A
A
And
the
problem
with
the
activity
Source,
firstly,
I-
don't
think
activity
Source
would
help
because,
like
when
I
looked
at
the
test
application,
they
are
using
they're
trying
to
like
count
the
number
of
ASP
net
core
incoming
requests,
which
is
happening
through
the
instrumentation
Library.
So
there's
no.
D
D
C
Okay
and
kind
of
related,
well
I
think
mostly
related
I
shared
a
link
to
an
issue
that
I
opened
up
against
the
runtime
like
a
couple
of
years
ago.
Just
about
multiple
activity,
listeners.
C
My
memory
is
kind
of
fuzzy
on
this,
but
I
think
I
encountered
this
based
off
of
our
own.
Some
of
our
own
unit
tests
that
happen
to
have
like
there
there's
an
activity
listener
that
the
Tracer
provider
instantiates,
but
then
the
unit
test
itself
or
the
fixture
itself
was
also
instantiating
an
activity
listener
of
its
own
I.
Don't
remember
why
or
this
test
is
probably
still
out
there,
but
anyways
it
was
creating
some
unexpected
behavior
and
so
I
guess
it's
kind
of
an
annoying
dance.
D
G
D
D
But
it
does
definitely
create
these
edge
cases
where,
if
you
had
multiple
sdks,
you
have
multiple
listeners.
You're
gonna
get
some
level
of
clobbering
because
there's
only
one
shared
instance.
What
does
it
then
mean
like?
Let's
say
you
have
two
Tracer
providers,
two
different
enrich
methods,
so
they're
going
to
be
enriching
the
same
instance,
they
could
clobber
some
tags.
You
could
get
weird
extra
tags
that
don't
make
sense
and
some
back
end
and
there's
definitely
issues
that
arise
from
this
design
choice.
D
C
C
D
D
Implementation,
we
could
actually
make
that
work
so
how
the
logging
framework
works
is
when
you're
interacting
with
ilogger,
and
you
call
DOT
log
it
fires
on
every
blogger
provider,
so
the
console
logger
gets
a
different
call
than
open
Telemetry
logger,
as
with
like
some
other
thing,
so
we
could
easily
support
it
just
by
having
multiple
logger
providers
in
there
and
then
each
pipeline
would
get
its
own
log
record.
That
would
be
like
super
easy
to
do.
D
F
C
If
these
kind
of
use
cases
become
important
for
tracing
I
mean
you
know
it
and
they
become
compelling
enough-
and
you
know
the
runtime
team
I
imagine
the
solution
probably
is
somewhere
within
the
activity
listener
like
like
the
ability
to
maybe
configure
an
activity
listener
to
explicitly
subscribe
to
only
things
that
it
says
you
know
and
and
make
copies
of
activities,
maybe
would
be
like
an
option
for
activity
listener
like
I
want
my
own
exclusive
copy
of
an
activity.
That's
not
seen
by
other
listeners.
D
G
D
C
Yeah
I
think
sampling
is
one
use
case
and
those
kinds
of
solutions
would
satisfy,
but
like
the
like,
the
security
kind
of
thing
I
think
it's
not
so
much
about
sampling,
and
it's
more
about
like
a
like.
This
I
want
this
activity
to
actually
be
redacted
yeah
well,
I
want
it
to
be
I,
want
it
to
be
exported
to
two
pipelines,
but
I
want
one
of
them
to
be
redacted
or
have
less
information
for.
A
Think
that
part
could
still
happen
depending
on
the
order
of
SDK
creation,
yeah.
D
D
Would
it
be
nice
if
you
set
it,
you
could
Fork
the
processor
chain
to
say.
Okay,
some
log
is
coming
through
I'm,
not
going
to
give
it
to
chain
a
but
chain.
B
is
going
to
see
it.
You
can't
really
do
that
today.
You'd
have
to
just
do
it
in
the
correct
order.
I
guess
there's
some
some
thing
that
makes
it
really
hard
to
do.
Forget.
Okay,
that's
best
done
through
the
spec,
probably.
E
D
F
C
C
Seems
like
it
might
be
here:
I'll
just
share
it
in
the
slack,
but
we
can.
We
can
talk
about
it
offline
if
we
want
to.
It
was
an
issue
that
I
responded
to
last
week
and
I
didn't.
C
It
wasn't
until
the
day
that
I
looked
at
the
stack
Trace
that.
C
C
This
kind
of
to
me
smelled,
like
it
might
be
an
instance
of
that
I
asked
this
guy
for
a
Repro,
because
I
said
like
I
couldn't
and
he
was
like.
Oh
yeah,
it
just
must
be
my
thing,
so
I'll
just
close
it.
So,
unfortunately
he
didn't
produce
a
Repro,
but.
C
D
F
D
Can
see
it
says
this
exception
was
originally
thrown
the
line
right
below
where
you
were
just
highlighted,
yeah
and
it's
that
thing
combat
the
extensions
I.
A
D
C
G
A
But
it
was
this
file
right,
like
the
load
context,
resolving
incompatible
the
extension
it
would
search
for
that.
There's
load
context,
resulting
this
is
the.
F
D
It
couldn't
load
diagnostic
source,
so
then
it's
like
falling
back
to
like
a
file
system
based
load
or
something
yeah
I
was
a.
G
G
D
D
D
D
A
G
A
F
A
F
F
C
D
I
D
D
G
C
D
C
But
I
don't
know
like
these.
Other
environments
that
are
I
mean
Azure
functions
is
I,
don't
know
what
limitations
the
Azure
functions.
Runtime
imposes
upon
these
things,
but,
like
these
other
environments,
that
people
are
struggling
with,
I
wouldn't
expect
would
have
weird
like
long-term
service
release.
Restrictions
like
Azure
functions
does.
D
C
G
A
A
Functions,
sorry
I
missed
the
like
a
partial
bit
of
the
discussion,
but,
like
I,
think
we
had
some
internal
customers
who
were
complaining
about
not
being
able
to
use
1.4
versions
of
Hotel
on
functions
and
then
they
reached
out
of
the
functions
team
and
the
functions
team
suggested
them
that
they
should
use
the
out
of
process
worker
mode
until
they
update
the
runtimes
in
their
in
process
version
like.
C
A
I
think
they
I
don't
think
they're
going
to
defecate
it,
but
I
I
think
they'll
just
update
it,
but
they
are
way
too
slow
to
update,
usually.
A
B
I
mean
my.
D
H
H
D
A
D
A
A
Like
all
the
internal
logging
that
functions
runtime,
does
it's
logged
as
information
like
the
severity
level
of
their
logs?
Is
always
information,
so
I,
just
you'll,
see
logs,
like
oh
functions,
hosts
starting
up
now
things
like
that,
so
it
kind
of
clutters
I,
don't
know
like.
Maybe
they
should
have
used
a
lower
log
level
for
their
with
their
runtimes
logging.
Interesting.
F
C
The
they.
C
One
interesting
thing
about
these
two
process:
models,
as
it
relates
to
us,
is
that
if
they're
using
the
in-process
model,
our
asp.net
core
instrumentation
gets
invoked
in
some
cases.
If
they're
using
the
isolated
worker
process
model,
it
does
not
so
they're
they,
they
have
like
an
end.
User
has
to
effectively
manually
instrument
their
functions
if
they
want
to
get
anything
out
of
open
telemetry.net.
C
It
doesn't
if,
if
they
have
it,
enabled
then
and
they're
using
the
end
process
model,
then
the
asp.net
core
instrumentation
does
get
invoked
and
you
get
some
automatic.
Just
activities
created.
C
There
was
just
an
issue
actually
submitted
yesterday
or
today
that
I
responded
to
of
a
guy.
Who
is
noting
the
difference
between
a
couple
of
different
Azure
functions
like
an
HTTP
trigger
and
a
timer
trigger.
F
C
E
C
Under
certain
scenarios,
right
you're
going
to
get
something
out
of
our
asp.net
core
instrumentation.
C
Not
something
you
can
generally
rely
on
with
functions.
A
C
Yeah
and
I've
spent
a
little
bit
of
time
like
looking
at
the
looking
at
the
like
the
Azure
functions,
API
or
the
SDK,
and
it
does
have
a
similar.
It
appears
to
have
a
similar
like
middleware,
like
architecture,
so
from
an
instrumentation
standpoint.
I
think
that
it
would
be
pretty
conceivable
to
to
have
a
like
a
middleware
component
that
you
could
inject
into
the
Azure
function
pipeline
that
that
could
do
like
the
activity.
C
Creation,
stop
start,
stop
record
metrics
whatever,
but
I
think
it
makes
sense
as
like
totally
separate
instrumentation
rather
than
you
know,
any
coincidental
Piggy
piggybacking
on
asp.net
core
yeah.