►
From YouTube: 2022-07-12 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
B
There
was
no
agenda
from
lexi,
jo,
and
I
see
which
switch
issue
added
one.
I
had
a
question
about
one
of
these
issues
that
was
created
on
the
dot
net
remain
reported,
so
this
is
very
similar
to
that
problem
that
we
discussed,
and
I
think
also
something
that
we
face
with
sql.
I.
A
A
B
B
Here
so
http
instrumentation
has
different
public
api
for
net
framework
versus
like
net
core
and
other
versions.
B
So
this
person
is
has
has
a
library
that
references
hotel
and
then,
when
he
he
is
running
into
that
issue.
Where,
like
this
middle
intermediate,
library
is
only
targeting.net
standard
2.0
and
when
he
runs
it
with
the
net
framework
application.
You
get
an
exception
saying
it
does
not
exist
like
the
the
api
that
he's
looking
for
so
as
far
as
I
remember
like
like,
if
he
has
the
intermediate
library,
also
target
everything
that
hotel
library
is
targeting,
it
should
work.
Fine
right
like
what's
what's
like
response
for
cases
like
these.
C
A
I
don't
know
that
I've
followed
the
whole
thing,
but
it
it
it's
from
the
sounds
of
it:
their
common
library,
the
common
dll.
They
say,
that's
compiled
with
net
standard
2o,
that's
the
one
that
references
whatever
open,
telemetry,
sdk,
probably
and
other
open
telemetry
dependencies,
maybe
and.
B
B
B
B
This
is
not
loaded
like
there's
only
this,
so
he
gets
saying
that
method,
not
wrong.
A
A
B
Yeah,
let
me
ask
him
about
that
then,
like
I
just
I
mean
I
have
a
feeling
you
might
come
back
saying
like
there
are
other,
like
applications
targeting
different
frameworks
that
are
consuming
this
common
library.
So
but.
G
E
I
feel
like
I've
read
somewhere
in
microsoft's
docs.
That
say
you
can
target
net
standard
2-0,
but
you
should
also
have
like
your
concrete
frameworks
in
there.
So
I
have
net
standard
2o
have
net.
You
know
four
seven
have
knit
five
just
so
in
these
situations
you
have
something
more
concrete
to
bind
to,
but
having
the
net
standard
2-0
in
there
gives
you
the
api
surface
I'll
see.
If
I
can
dig
that
up
somewhere.
A
B
Yeah
and
also,
I
guess,
from
a
package
that
the
dot
net
package
validation
tool
which
we
haven't
moved
to
yet
I
think
that
would
complain
about
this,
like
it
expects
the
api
public
api
service
to
be
the
same
across
frameworks
as
well.
I
mean
we
can
suppress
all
that,
but
I
think
that's
an
expectation.
E
B
Cool
yeah
I'll
reply
to
this
issue
and
ask
him
if
he
can
update
his
target
framework
for
the
common
library.
C
D
B
A
Well,
I
mean
technically
these
instrumentation
packages
are
not,
you
know
stable
yet,
so
maybe
there
is
something
better.
We
can
do
like,
like
michael
said,
like
split
up
the
packages
or
something
if
we
need
to
maybe
but.
A
D
Yes,
I
have
a
quick
follow-up
question
on
that,
so
I
think,
like
for
the
dotnet
framework,
could
be
the
the
options
that
we
have
it's
only
for
dotnet
framework.
So
even
if
let's
say
we
allow
the
next
standard
one
here,
the
they
won't
be
able
to
use
the
options,
because
that
only
comes
in
the
net
net
462
target.
D
B
D
This
yeah,
that
is
only
available
like
if
they
want
to
use
they
have
to
use
this
one
like
if
they
want
to
use
the
http
client
in
net
framework.
I
think
our
documentation
says
that
they
have
to
configure
the
http
web
request,
instrumentation
options,
so
even
if,
like
I
think
we
allow
it
here,
then
we'll
have
to
do
something
about
that.
So
if
you
go
like
one
level
up,
I
think
we
have
a
statement
like
in
the
just
go
to
like
read
me:
yeah
scroll
down,
advanced
configuration.
B
D
E
So
I
think
what
will
happen
is
if,
if
they
add
the
targets
in
their
common
library,
then
this
will
manifest
as
a
compilation
error
in
their
net
framework
or
net
core,
whichever
one
is
missing
it.
So
what
they'll
have
to
do
is
implement
the
same
sort
of
pre-processor
directives
in
their
library
which
then
should
propagate
to
whatever's
consuming
it
and
it
it
should
all
work.
They'll
just
have
to
solve
this,
then
in
their
intermediary
libraries.
That
kind
of
make
sense.
B
Okay,
let's
move
to
the
next
agenda.
B
D
Yeah,
I
just
wanted
to
ask
if,
like
what
everyone
thinks
about
merging
the
dot
net,
seven
branch
into
mean
right
now
I
had
a
brief
conversation
with
sujo
yesterday
offline.
D
I
believe
the
reason
to
create
dotnet
7
branch
was
because
we
wanted
to
do
a
stable
release
for
our
prometheus,
but
the
spec
it
is
not
stable
yet
so,
if
we
do
this,
we
won't
be
able
to
release
any
stable
until
before
november
when
the
dot
net
seven
releases.
D
So
the
the
proposal
that,
like
we
have,
is
to
merge
dot
net
7
branch
by
like
july
end.
We
wait
for
the
prometheus
spec
to
get
stable.
If
it
doesn't,
then
we
just
like
wait
for
another
three
months
to
do
the
stable
release
if
the
prometheus
gets
stable
in
between
that
time.
So
just
wanted
to
get
like
what
what
everyone
thinks
about
that
that
will
make
it
easier
to
do
any
merging
for
the
dot
net.
Seven
changes
that
we
are
doing
in
the
donut
7
branch
right
now.
A
That
sounds
good
to
me.
I
had
also
spoken
mesito
a
while
back
on
this
and
yeah.
If
it
seems
like
prometheus,
isn't
gonna
stabilize
then
yeah.
I
think
it'd
be
much
easier
to
work
on
main
rather
than
the
two
branches.
A
E
E
E
Get
it
out
on
the
current
it
just.
I
think
it
makes
it
a
little
easier
for
people
to
take
it
play
with
it.
Give
us
some
feedback,
because
the
risk
with
the
log
record
pooling
is,
if
there's
a
bug
in
there
and
it's
writing
over
records
in
the
pool
or
it's
taking
two.
You
know
it
could
get
really
messy.
So
there's
some
risk
there
to
the
polling.
So
I'd
like
to
get
some
eyes
on
it.
Some
users,
before
we
just
drop
it
on
the
world.
A
A
It's
got
some
ugliness
to
it,
but
it's
the
one
for
limiting
the
attribute
length
stuff
and
I
think
the
same
kind
of
argument
there
would
apply
if
people
who's,
who
would
be
interested
in
trying
that
out,
may
not
be
ready
to
take
a
preview
version
of
the.net
7
diagnostic
source
yeah.
This
one.
B
C
B
A
Yeah
I'll
speak
to
this
one
yeah
mike-
and
I
were
talking
about
this
one
a
few
days
back
and
it
sounds
like
unting.
You
have
expressed
some
interest
in
maybe
helping
out
here
so
I'll
share
my
current
thoughts.
If
you
scroll
down
just
a
little
bit,
I
had
kind
of
bulleted
out
some
some
options
here.
A
So
actually
let
me
just
take
a
step
back
here
so
like
basically,
the
open
telemetry
protocol,
the
exporter,
depending
on
the
target,
so
the
net
standard
2o
target
of
it
currently
references
in
older
grpc
library
that
is
on
the
path
to
deprecation.
A
So
the
new
library
now
supports
net
standard
2o
and
folks
would
like
to
use
it
because
the
older
library
has
some
like
kind
of
it.
Has
some
nasty
like
native
dependencies
that
get
pulled
in
and
it's
being
deprecated,
so
you
know,
there's
a
fear
that,
like
you
know,
it
won't
be
supported
or
like
security
patches
won't
be
applied
to
it
and
so
on
in
the
future.
A
So
folks
are
hot
on
using
the
the
new
grpc
library,
so
that
leaves
us
in
a
state
of
kind
of
deciding
what
to
do
with
the
exporter
and
just
off
the
cuff
I
some
of
these
options.
I
haven't
really
researched
sufficiently
enough,
so
I
don't
know
whether
they're
actually
legit
options
or
not,
but
I've
outlined
kind
of
three
paths
here.
So
I'll.
A
Just
kind
of
talk
through
those
real
quick
I'll
speak
first
to
option
three,
because
because
that's
the
one
that
most
recently
mike
and
I
kind
of
thought,
maybe
was
the
best
option
so
basically
a
while
back
the
http
client
factory
option
was
added
to
the
grpc
options.
Like
sorry,
our
grpc
exporter
configuration
sorry,
I'm
saying
everything
wrong.
Our
exporter
configuration
has
an
http
client
factory
configuration
option.
A
Currently,
it's
only
being
used
by
the
http
flavored
exporter,
but
there's
nothing
to
say
it
couldn't
be
used
by
the
grpc
flavored
exporter.
So
that's
to
say,
when
you
configure
to
use
grpc
the
new
grpc
library
uses
this
uses
http
client
underneath
the
scenes,
so
this
would
enable
folks
if
we
expose
that
option
to
the
grpc
exporter.
A
This
would
enable
folks
who
want
to
use
the
new
library
on
like
net
standard
2o
targeted
framework.
So,
like
I
think
this
user
is
probably
using
that
framework.
A
A
If
you
don't
mind
clicking
that
docs.microsoft
link
yeah,
so
basically
the
new
library
it.
You
know
that
first
sentence,
there's
not
full
http
2
support
in
those
versions
of
of
the
framework,
but
there's
a
number
of
ways
to
get
around
that.
So
this
is
what
I
mean
like
if
we
expose
that
http
client,
factory
and
and
mike
has
a
code
snippet
in
that
issue.
That
basically
demonstrates
what
this
article
is
speaking
to.
It
would
allow
an
end
user
to
configure
their
the
environment
properly.
A
For
this
to
work,
unfortunately,
the
downside
to
this
option
is
that
it
would
potentially
break
or
not.
Potentially,
it
probably
would
definitely
break
folks
who
are
currently
consuming
this
package,
our
exporter
package
in
a.net
framework
kind
of
environment.
You
know
they're
working
happily
today,
but
all
of
a
sudden.
If
we
were
to
release
if
we
were
to
drop
the
old
grpc
library
and
they
we
were
to
require
them
to
go
in
and
add
this
configuration.
That
would
be
a
breaking
change
for
them.
A
So
that's
the
downside
to
option
three,
as
stated
by
me
in
the
issue,
so
then
another
thing
that
mike
and
I
talked
about
was
well.
You
know
we
could
use
this
as
an
opportunity
to
do
what
some
of
the
other
sigs
have
done,
and
that
is
to
instead
of
have
this,
like
monolithic
exporter
package,
a
separate
package
for
the
http
exporter
in
a
separate
package
for
the
grpc
exporter.
A
Basically,
thereby
not
breaking
anybody
currently
using
the
package
on.net
framework,
so
that
is,
that
is
a
legit
path.
That's
one!
That's
one
path
that
I
think
we
could
pursue.
A
There's
one
other
path
that
which
is
probably
best
articulated
by
option
one
here,
there's
one
other
path
that
I'd
like
to
explore
a
little
bit
more.
I
don't
know
whether
it
will
actually
work.
It
requires
a
little
bit
of
due
diligence
and
I
just
haven't
dug
into
it
yet
so
that's
to
basically
not
rely.
It's
basically
have
the
library
continue
to
manage
the
channel
completely
internally,
and
my
thought
here
would
be
to
detect
the
run
time
so
pop
over
back
over
to
that,
like
docs
that
microsoft
dock
tab
again.
A
So
if
we
were
able
to
detect
which
of
the
runtimes
is
is
running,
then
we
should
be
able
to
do
the
correct
thing
per
this
documentation
based
off
of
the
runtime,
and
I
think
that
that
would
work
if
you
scroll
down
a
little
bit.
The
http
handler
configuration
section
talks
about
like
how
to
make
things
work
in
like
the
uwp,
xamarin
and
unity
environment
like
if
we
could
detect
those
environments,
then
we
should
be
able
to
construct
the
channel
accordingly,
but
I
just
was
reading
this
beforehand.
A
I
think
this
is
the
sticking
point
that
actually
may
make
it
make
this
not
a
legit
option
under
the
dot
net
framework
portion
of
this.
I
swear.
I
read
this
like
maybe
a
number
of
months
ago.
I
swear
that
it.
The
requirements
was
windows
10
or
later,
but
now
it
says,
windows
11
or
later,
so
that
has
me
concerned,
but
basically
for
a
net
framework
environment.
A
You
have
to
configure
the
usage
of
this
win,
http
handler,
which
supports
http
2,
and
it's
that
would
require
a
different
like
dependency
for,
like
a
like
a
net
framework
build
of
the
of
the
grp
or
sorry
the
otlp
exporter.
I
think
that
would
be
okay.
A
But
it's
this
portion
that
I
I've.
I
did.
Some
google
searches,
like
you
know,
http
client,
on
net
framework,
http
2
and
I'm
getting
some
conflicting
statements
of
support.
Like
this
says:
windows,
11
and
windows,
server,
2022,.
H
A
A
I
said
a
lot
of
words,
so
I'm
curious
if
folks
have
questions
or
if
they
already
have
information
that
answers.
Some
of
these
questions
that
I
have.
B
So
like
with
this
approach,
it's
also
going
to
be
tough
for
us
to
like
validate
and
test
that
it
works
fine.
You
know
all
of
these
different
scenarios
right.
A
B
We
would
like,
based
on
whatever
is
listed
here.
We
would
follow
that
to
come
up
with
the
http
handler,
but
like
still
like,
when
it
comes
from
yeah,
I
guess
like
we
won't
have
like
tests
for
different
run
times.
That
way,
though
right
so
I
I
feel
like
it's,
this
one
might
be
more
cumbersome
to
just
check
if
things
are
implemented
correctly
or
not,.
A
Yeah
definitely
it
would
require
a
fair
amount
of
due
diligence
and
maybe
maybe
yeah
and
to
your
point-
maybe
that's
just
not
worth
it.
I
think
some
of
those
other
I
mean.
I
know
that
for
some
of
those
other
runtimes,
I
think
we
already
have
some
compatibility
issues
like
xamarin
like
more
core
compatibility
issues.
You
know
beyond
this,
so
I
wonder
if
you
know
we
need
to
be
concerned
with
some
of
those
other
runtimes.
A
I
think
its.net
framework
is
obviously
the
the
most
important
one
and
even
that
we
don't
test
today,
because
it
requires
you
know
we,
we
don't
have
like
an
integration
test
today
for
the
telemetry
protocol
exporter
that
runs
on
like
a
windows
container,
you
know
via
the
ci
and
all
that,
but
we
probably
want
to
do
that
if
we
were
to
pursue
this
yeah.
B
So,
with
the
other
two
approaches,
one
was
like:
we,
we
used
the
new
package,
which
now
has
the
capability
to
support
netstandard
2.0
versions,
but
then
that
will
cause
a
breaking
change
for
the
existing
users
right.
That
was
the
that
was
one
of
the
options.
A
A
Yeah,
if
we
keep
one
package
and
we
simply
drop
the
old,
the
dependency
on
the
old
grpc
library
will
break
people,
because
it's
not
that
they
wouldn't
be
able
to
fix
themselves,
but
they
would
have.
They
would
have
to
go
in
and
then
configure
via
this
http
client
factory
option
things
to
work
within
a.net
framework
environment.
A
A
At
some
point,
I
think
we
should
drop
that
just
simply
because
that
package
is
being
deprecated.
I
think
next
year
it's
slated
to
be
deprecated,
but
I
think
at
that
point
you
know
we'd
probably
want
to
consider
like
a
major
version
bump
of
this
of
this.
B
So,
like
the
option
to
split
packages,
is
the
third
one
like
I'm,
I
don't.
What
is
it
not.
A
Sorry,
you're
right,
yeah,
the
the
split
packages
thing
was,
is
not
actually
articulated
there.
It's
it's
related
to
the
third
one
in
the
sense
that
that's
that's
how
the
package
would
work,
but
no
that
would
just
came
out
of
conversation
between
me
and
mike.
So
what
we
would
do
to
avoid
this
breaking
change
right
is
to
split
the
packages,
an
http
version
and
a
grpc
version.
That's
what
a
lot
of
the
other
sigs
have
already
done.
A
They
have
basically
two
different
packages,
so
we
would
mimic
that
and
the
grpc
flavored
package
that
would
that
would
just
reference
the
new
grpc
library
and
would
require
right
if
somebody
in
a.net
framework
environment,
if
they
wanted
to
consume
that
package,
it's
a
new
package
and
it
would
require
them
to
configure
things
via
this
http
client
factory
option
to
make
things
work,
and
that
should
be
okay
right,
because
they're
they're
changing
their
dependency,
and
so
it's
reasonable
to
expect
that
they
would
need
to
go
in
and
configure
things
correctly.
H
First
and
then
yeah
after
that,
maybe.
H
Can
you
hear
me
clearly
yeah
yeah?
I
was
saying
that
I'm
thinking
to
dig
more
into
the
third
option
first
and
then,
after
that,
probably
from
there
just
try
a
bit
more
with
option.
One.
B
Yeah
I
mean,
I
think
third
option
sounds
good.
Also,
it's
helping
us
solve
some
other
problems
with
the
self-signed
certificates
and
stuff.
B
What
was
our
initial,
like
rationale
behind
having
a
single
package
versus
having
dedicated,
http
and
grpc
packages
like
what
was
the
benefit
other
than
like
managing
like
the
maintaining
spot.
B
Like
did
we
did
we
decide
back
then,
when
we
like
just
had
we,
when
we
decided
to
have
only
one
package
which
would
handle
both
grpc
and
http
like
did
we
choose
that
approach
over
having
separate
packages
or
any
specific
reason
or
like.
A
I
think
if
we
were
to
do
it
all
over
again
today,
we
probably
would
have
landed
on
two
packages.
Anyways.
The
history
is
that
we
didn't
have
http
support
when
we
originally
went
1.0
with
with
everything,
so
we
only
had
grpc
and
the
package
was
just
generically
named
right,
open
telemetry
protocol
exporter,
whatever
we
introduced
the
http
support
later,
and
at
that
point
you
know.
D
A
Put
it
in
the
in
the
same
package,
which
you
know,
I
guess
has
the
unfortunate
aspect
of.
If
we
do
publish
now
three
packages
right,
we'll
still
have
this
old
package
and
then
the
two
new
ones
you
know
will
just
there
will
be
more
more
for
a
end
user
to
consider
you
know
which
one
should
I
use
kind
of
question.
I
don't
think
it's
the
end
of
the
world,
but
that
that's
the
main
reason
why
I
was.
A
I
still
had
the
question
on
my
mind
of
whether
we
could
keep
the
the
package
surface
area
simple.
It
was
mainly
mainly
from
the
standpoint
of
of
making
things
easy
for
the
end
user
versus
you
know,
making
things
easier
for
like
us
to
maintain.
A
But
that
said
again
I
don't
it's
kind
of
seeming
like
that's,
not
even
an
option
anyways.
So
I
would
be
I'm
fine
pursuing
the
two
package
approach.
I
think
the.
A
The
approach
I
might
take
there
is
is
to
in
in
mike
and
mike's
comment
down
below
there
introduce
that
first
in
the
in
the
existing
package,
because
that
has
some
benefit
anyways
to
folks.
You
know,
besides
this
whole,
like
net
standard
2o
target,
exposing
that
http
client
factory
option
in
the
existing
package
has
benefits.
A
B
Yeah
sounds
good.
I
think
third
option
is
something
to
look
at.
A
Yeah
in
muting,
if
you
wanna,
I
mean
we
can
talk
more
about
this
offline.
If
you
want
to
spend
some
time
looking
at
the
package
and
considering
things
and
coming
up
with
any
questions
to
get
started,.
D
H
Yeah
I'll
do
some
research
ask
this
first
and
then
thank
you.
If
I
have
any
questions.
B
F
F
It
looks
like
the
wcf1
has
failed
once
and
also
there
is
some
timing
issue
with
the
with
the
the
metrics
test
or
the
event
counter
test.
So
I'm
not
entirely
sure.
So
the
test
type
setup
are
like
really
similar
to
the
ones
running
inside
with,
I
think
app
insights
tests
are
very
similar.
So
there's
always
like
a
timing
component
to
this,
where
you're
asking
to
be
a
subscriber
of
event,
counter
metrics
and
then,
if
it
aggregates
within
the
interval.
F
So
if
you
say
too
long
the
interval
passes
and
then
you
don't
get
any
matrix
and
if
you
say
too
short
that
it
hasn't
had
enough
time
to
communicate.
So
I'm
not
sure
if
there's
a
good
solution
or
if
anybody
can
point
me
in
a
direction
to
further
fine
tune.
It
yeah
I'd
appreciate
some
help.
I
think,
but
and
any
other
obviously
feedback
I
can
resolve
so
then
we
can
merge
this
and
work
on
the
configuration
piece,
which
is
what
cj
wanted
next.
B
F
I
I
think
they're
okay,
like
so
definitely
on
my
machine,
I
kind
of
ran
it
quite
a
few
number
of
times
added
cpu
load,
but
there
is
some
kind
of
flakiness
on
the
build
server.
So
I'm
pointing
out
that
there
are
other
tests
that
have
the
same
issue.
So
I
don't
know
what
your
experience
with
those
is.
I
mean.
C
F
Yeah,
I
I
know
what
you
mean
yeah,
so
I
I
I
do
think
that
is
because
of
the
nature
of
the
timing
thing
that
maybe
this
one
is
more
flaky
than
others,
the
one
I
wrote,
especially
where
you're
like
expecting,
I
think
incrementing
counter
metrics,
where
we
fire
off.
F
We
actually
use
the
instrumentation
to
to
create
like
create
a
event
counter
source,
basically
a
test
source,
and
then
we
do
something
specific
and
then
wait
for
the
interval
to
expire
and
then
make
sure
it
does
the
right
same.
It
does
the
correct
thing
and
that
one
seems
to
be
more
likely
to
fail.
I
will
I
will
look
somewhere
and
see
if
I
can
get
some
clues
from
the
app
insights
code
repo
as
well,
because
I'm
sure
whatever
I'm
doing
here
is
very
similar
to
what's
there
and
it's
nothing
specific
to
open
telemetry.
F
I
don't
think
it's
not
anything
that
open
telemetry
project
is
doing
it's
to
do
with
the
nature
of
how
encounters
are
implemented.
So
I'll
spend
some
more
time
there
but
yeah
like.
Let
me
know
any
other
feedback.
B
Yeah
I
mean
yeah,
most
likely
I'll
just
merge
this
br
in
like
the
next
few
hours,
and
then
I
think
you
yeah
like.
If
you
want
to
like
a
package
release
for
this
a
beta
version,
then
you
have
to
just
update
the
create
a
pr
to
update
the
changelog.
F
Gotcha,
so
I
kinda
wasn't,
I
created
the.
I
don't
think
I
saw
where
you'd
market
an
alpha
or
not.
F
B
An
alpha,
no,
you
just
have
to
okay.
I
think
this
needs
a
like
a
change
log
file,
change,
log,
markdown
and
then
like.
If
you
want
to.