►
From YouTube: 2022-06-07 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
B
I
think
we
can
start
now
yeah,
you
can
add
your
name
to
the
list,
so
nothing
in
the
agenda.
So
I
just
can't
share
the
update
that
we
finished
the
1.3
release
last
week.
B
So
any
tiers
which
were
like
temporarily
put
on
hold
can
now
be
more
so
I'm
starting
to
look
at
all
the
pending
pr's
and
merging
them
on
by
one.
We
could
quickly
go
through
the
open
prs
just
to
see
if
there
is
anything
which
requires
discussion.
B
So
this
is
a
draft
I
think,
which
is
working
on
incorporating
new
changes
from
http
client,
so
no
need
of
any
discussion.
This
one
is
following
recently
merged
specification
on
how
to
handle
http
redirect.
So
I
think
we
uploaded,
but
our
blinds
had
left
a
comment
about
potentially
having
an
issue
with
the
http
client
for
net
framework.
B
So
denise
has
resolved
saying
that
it's
not
an
issue,
but
I
have
explicitly
asked
for
an
upload
from
blanche,
because
the
dot
net
framework
version
of
http
client
is
a
big,
complicated
thing
and
we
are
using
lots
of
perfection
to
stitch
things
together.
So
I
have
wait.
I'm
just
waiting
for
like
an
explicit
approval
from
michael,
so
that's
the
it's
a
very
small
change.
It
implements
a
a
small
section
from
the
specification,
so
we
can
merge
it
once
michael
gives
a
blessing.
B
This
one
is
still
trans.
I
think,
like
let's
wait
for
michael
to
come
back.
This
one
is
already
decided.
I
believe
that.
B
A
I
think
this
one
just
this.
A
A
new,
more
performant
way
of
injecting
extracting
context,
I
felt
like
the
api,
was
a
little
bit
complicated.
I
I
reviewed
it.
I
think
that
I
mean
my
take
was
that
let's
we
can
merge
it.
If
we
all
think
it's
it's
a
good
worthwhile
thing,
and
now
that
we're
past
1.3,
you
know
we
might
get
some
feedback.
B
A
It
would
be
obsoleting
the
old
methods,
so
it's
not
a
breaking
change
or
well.
I
mean
I
guess
it
depends
on
how
we
you
know
approach
it.
B
B
Versus
performance
but
yeah
I'll
have
to
see
what
exactly
is
this
then?
Based
on
that?
I
can
share
my
opinion,
but
anyway,
nothing
like
super
urgent,
michael
mentioned
that
this
is
just
a
nice
improvement.
Not
like
someone.
I
don't
think
anyone
has
ever
complained
about
the
performance
of
propagators
themselves,
so
we
just
wait
for
it
as
soon
as
I
get
some
free
time
I'll
get
back
to
it.
B
Any
other
comments
which
were
open
thing:
okay,
yeah
there
are
benchmarks:
okay,
yeah,
let's
come
back
to
it,
but
this
one
I
think
it
was
just
merged
from
me
again.
So
I
just
wait
for
that-
build
to
be
green
before
munching.
This
one
is
fairly
big,
several
pieces.
Some
of
them
would
be
immediately
going.
B
I
mean
it
won't
be
going
public
immediately
except
the
log
emitter
thing,
which
is
the
a
related
thing,
but
it
has
like
some
other
niceness
which
improves
the
performance
of
log
record.
So
I
don't
know
whether
michael
intends
to
let
that
separate
one
or
I
need
to
check
with
him,
because
it's
still
marta's
draft,
oh
yeah.
B
I
think
I
think
I
understood
what
he's
waiting
for
that
would
be
the
last
year,
so
it's
probably
like
trying
to
extract
things
out
of
it
into
shorter
pr's,
but
I'll
definitely
check
with
you
on
that
yeah.
So
this
is
a
new
spec.
I
mean
not
newspaper
relatively
new
spec,
which
allows
someone
to
write
a
adapter
for
logging
libraries
other
than
I
logger.
B
It
involves
like
exposing
things
in
log
record
and
a
bunch
of
other
performance
optimizations
like
log
record,
so
I
think
we
can
definitely
good
idea
to
wait
after
1.3,
which
we
just
did
so.
We
can
now
start
like
reviewing
and
merging
like
piece
by
piece
or
keeping
things
internal
and
merging
all
in
one
shot
for
this
one.
I
think
this
was
approved.
We
just
decided
to
delay
it
for
post
1.3.
B
So
since
post
1.3
is
done
like
I
can
ask
christian
to
rebase,
because
I
didn't
have
the
permission
to
read
this,
this
one
yeah
I'll
just
thinking
and
see
if
we
can
use
it,
I
think
he
yeah
he.
I.
A
B
He
rebased
it,
but
you
know
like
they
use
the
company
prime,
so
I
don't
think
we
have
the
permission
to
push
to
that
branch.
Oh,
oh,
I
see
yeah.
So
in
general
I
have
found
that
with
dinar
trace
they
use
like
dryness
denaturates
branch,
not
individuals.
They
don't
allow
push
from
even
maintainers.
A
I
think
I
I'm
still
in
the
opinion
that
I
think
configure
resource
would
be
a
better
name
than
configure
resources.
I
don't
have
a
strong
opinion,
but
if,
if
others
agree
with
that,
I
think
I
think
he's
willing
to
make
that
change
in
his
last
comment.
So
I
see
so
you
are
saying
it's
configured
resource.
B
Is
a
better
one
instead
of
resources
right,
that's
how
I
think
about
it.
Yeah,
I
think
it's,
I
think,
logically,
that's
what
I
felt.
I
I
remember
like
seeing
yeah
this
comment.
Okay,
so
maybe
we'll
give
another
opportunity
for
folks
to
come,
but
either
way
it
shouldn't
be
like
a
major
issue,
because
even
if
you
make
it
public,
we
still
have
the
opportunity
to
change
it
like
within,
like
whenever
we
release
the
next
table,
but
mostly,
I
think
this
vr
is
good.
B
B
B
B
I
think
it's
all
good,
like
we
just
need
to
rebase
with
the
base
branch
and
then
merge
it.
I
left
a
comment
about
the
even
source
because
we
already
merged
a
different
pr.
Now
there
is
no
api,
even
source
anymore,
like
we
like
to
sleep
without
so
you
can
just
give
it
a
control
to
replace
with
that
one.
B
B
A
Basically,
to
promote
this
right,
okay
yeah-
this
has
been
prometheus,
is
basically
the
last
one
that
this
work
needed
to
be
applied
to.
So
I
think
this
is
pretty
much
good
to
go
now.
Okay,
I'll,
take
a
look
I'll.
B
Put
a
reminder
to
remain
like
review
myself,
just
to
give
like
one
more
nice
before
we
merge.
I
think
riley
mentioned
that
he's
working
on
like
stabilizing
the
prometheus
specification
itself,
so
I'll
come
back
to
that
in
a
moment,
let's
go
through
the
prs
and
then
come
back
this
one.
B
I
wanted
to
ask
so
the
feature
request
is
for
adding
the
equivalent
of
filter
to
matrix
as
well.
So
we
have
the
index
and
filter
capabilities
in
most
of
the
instrumentation
libraries.
Let's
take
this
one
yeah,
so
the
ask
is
to
have
the
similar
thing
for
matrix
as
well.
It's
the
current
issue
is
specifically
two
filter,
so
if
there
there
are
like
some
matrix
or
some
some
paths
or
some
conditions
for
which
metrics
are
not
to
be
generated,
the
feature
request
is
to
allow
filter
api
similar
to
tracing.
B
B
The
reason
why
I'm
a
bit
concerned
is
for
matrix,
I
mean
not
for
metrics,
like
in
general,
like
all
these
filters
and
integers
are
like
our
own
invention
it.
It's
not
really
following
any
specification,
so
we
added
it
because
it
was
deemed
useful
because
in
tracing
there
was
no
other
like
neat
way
to
filter
out
things,
at
least
when
we
added
this
initially,
because
the
regular
activity
processor
did
not
allow
access
to
the
context.
B
So
that's
why,
like
this,
was
considered
like
a
reasonable
trade-off,
even
though
we
know
that
it's
not
backed
by
a
spec
for
matrix,
usually
there
is
not
much
cost
if
we
add
like
one
more
metric,
because
it's
anyway
pre-aggregated,
but
that's
not
the
case
with
traces.
Every
single
span
adds
to
the
cost.
I
mean.
B
So
that's
why
we
really
decided
to
have
this
thing
for
metrics,
I'm
not
sure
whether
it's
worth
the
cost
of
exposing
like
public
apis,
because
we
have
like
many
instrumentation
libraries
and
like
for
some
sort
of
consistency.
We
would
expect
everyone
to
adhere
to
the
filter
and
enrich
option
so.
A
B
Would
probably
be
like,
if
you
do
that
suppressing
then,
like
we
have
to
check
the
flag
in
every
metric
the
code,
we
generally
try
to
avoid
any
extra
checks
in
metrics
just
to
keep
it
on
the
highest
performance
bar
right.
So
if
we
support
the
thing
like
the
context
thing,
then
we
have
to
do
a
context
check
in
every
hot
path.
B
So
it
might,
it
might
be
okay.
We
have
to
actually
measure
it,
but
like
in
general,
we've
been
trying
to
be
very
cautious
with
the
performance
in
matrix,
so
in
general,
that's
the
expectation
of
also
matrix
should
be
like
the
highest
performing
thing.
B
B
So
it
should
be
like
straightforward
to
like
filter
it
out
like
in
the
ui
like
wherever
people
are
querying
the
metrics,
because
it
doesn't
really
cost
to
add
one
more
value
to
a
dimension.
For
example,
it
could
be
url
and
they
will
have
one
one
extra
url
for
the
health
check.
So
I
mean
if
it
is
traces,
then
it's
a
different
thing,
because
every
time
that
hit
you
generate
a
span
and
it
has
to
be
exported
so
and
depending
on
which
vendor
they
are
using,
they
have
to
pay
for
it.
B
So
I
like
wait
for
like
anyone
else
to
comment
like
if
there
are
any
opinions
on
this
one
in
more
than
that,
my
general
concern
is
like:
if
you
expose
anything
which
are
not
like
backed
by
the
spec,
then
there
is
a
potential
that
in
the
future
the
spec
would
come
with
something
similar
to
this
and
then
we'll
have
to
scramble
to
like
either
adjust
this
one
to
match
the
spec
or
like
throw
it
away
in
favor
of
whatever
the
spec
recommends.
B
B
Okay,
this
is
again
similar
changes,
http
client,
so
both
http
client
and
sp
net
core
have
started
using
the
activity
source
way
of
creating
activity,
starting
with
dotnet
seven
onward.
So
we
want
to
detect,
like
some
content
detection,
whether
we
are
running
dot,
net,
seven
or
not,
and
based
on
that
we
have
to
have
a
like
avoid
the
reflection
hacks.
We
we
do
like
a
lot
of
hacks
for
experiment,
core
and
http
client,
so
hope
is
with
dotnet
7
onwards.
B
We
should
be
able
to
avoid
all
sort
of
hacks,
so
those
pr's
are
like
still
actively
being
worked
on
the
espana
http
client,
okay,
this
one,
I
think
I
looked
at
it
like
previously,
and
I
left
some
comments,
but
that
original
order
like
abandoned
that
pr
or
it
went
still.
I
don't
know
whether
it's
the
same
order.
Maybe
you
can
find
this
issue.
This
is
the
issue,
so
there
was
a
pr
which
added
this
oh
yeah,
this
this
different
version.
So
there
was
this
pr.
I
left
some
comments.
B
I
think
this
one,
no
okay,
I'm
going
in
circles.
I
need
to
find
anyway,
so
this
pr
is
reasonable.
It's
basically
like
very
similar
to
what
we
have
for
all
the
other
instrumentations
like
core
and
asp.net,
that
we
are
adding
filter
capabilities
to
sql
again
the
reasonings
like
give
access
to
the
context.
B
C
B
The
tool
is
saying
that
it
is
increasing
coverage
yeah,
it
says
point
three,
so
maybe,
but
actually
this
is
not
really.
First
of
all
yeah
actually
right.
This
is
actually
showing
the
right
thing.
It
looks
like
it's
increasing
the
coverage
so
yeah,
so
no
product
change
just
additional
tests
to
improve
the
coverage.
So
this
one
is
improving
the
coverage
for
default
meter
provider
builder
indirectly,
by
adding
test
to
the
extension
for
hosting
parties
and
the
other
one
is
purely
for
the
newly
addressed
very
straightforward.
B
Close
this
sorry
yeah
yeah,
thanks
mothra
for
trying
this
any
other
appears.
So
this
one
thing.
This
is
something
which
I
mentioned
earlier.
So
it's
done
in
relation
to
the
pooling
of
log
records.
So
it's
like
some
internal
tweaks
to
fix
some
very
corner
case
threading
issues.
So
just
take
a
look.
If
things
looks,
okay,
mark
approve
or
ask
questions.
B
B
This
means
we
have
to
take
a
dependency
on
that.net
7..
So
once
we
do
that,
we
won't
be
able
to
release
anything
stable
from
the
repo
because
dependencies
at
the
very
root
thing
itself,
so
any
package
would
automatically
be
depending
on
diagnostics
or
servants,
so
we
won't
be
able
to
release
it
by
now,
but
I
mean
earlier
than
november.
So
what
we
are
waiting
on
is
I'm
waiting
to
see
if
we
can
release
prometheus
as
stable
in
the
next
one
month
or
two.
B
If
that's
the
case,
then
we'll
need
to
do
a
1.3
to
release
a
stable
version
of
prometheus,
because
that
doesn't
require
the
2.7
change
and
then
release
another
one
like
1.5.
It
would
be
at
that
time
to
match
the
dot
net
7
release
time,
but
I
cannot
make
that
decision
as
of
today
I'll
discuss
with
alan
and
change
offering
and
see
if
we
have
a
good
conference
that,
from
this
is
going
to
be
stable
in
the
next
two
months.
We
should
definitely
do
that.
B
So
in
practice,
what
it
likely
means
is,
as
we
were
discussing
offline
with
other
maintainers,
we'll
create
a
private
branch,
a
not
private
branch
like
a
separate
branch
and
we'll
merge
all
the
suburban
related
changes
into
that
branch
and
maintain
it
there
so
that
the
main
main
trend
is
still
open
for
regular
pr's
for
1.3.
B
But
we
can
make
that
decision.
Once
I
haven't
attended
the
spec
meeting
for
metrics.
I
don't
know
how
close
the
from
this
thing
is.
Riley
says
it's
very
close,
so
I'll
check
the
status
and
then
update
by
next
week.
B
So
as
of
now
we'll
operate
with
the
assumption
that
we
are
having
a
one
more
release
by
dotnet.
Seven
time
play
similar
comment
about
the
login
exporter
for
otlp.
The
protofiles
are
still
allowed,
so
technically
we
can
call
it
stable,
but
the
pr
switch
client
is
working
on
for
log
record.
B
They
are
like
really
important
thing
to
have,
so
we
are
better
off
like
waiting
for
them
to
merge
before
we
call
things
as
stable
and
also
there
are
like
really
debatable
things
which
we
do
in
the
log
exporter
like,
especially
in
that
transformation.
How
do
we
translate.
B
B
B
On
this
I
mean
this
is
a
area
which
I'm
really
interested
in.
How
do
we?
How
do
we
expect
or
how
do
users
end
users
expect
the
scopes
to
be
exported
in
otlp?
So
if
you
have
like
customers,
please
ask
them
for
feedback.
Are
they
okay
with
this
approach,
or
are
they
okay
with
something
else
yeah
so,
based
on
the
feedbacks
like
we
need
to
adjust
how
we
deal
with
that
and
we
need
to
finalize
it
before
we
call
it
a
yeah.
B
B
It's
like
looking
for
like
contribution
and
like
looking
for
issues,
one
suggestion,
as
I
asked
earlier,
is
we
want
someone
to
look
at
the
ap
compact
thing.
B
Very
flaky,
like
several
prs,
are
being
affected
by
it.
So
if
you
can
look
at
the
microsoft
new
documentation
and
adopt
it
here,
that
would
really
help
so
just
bring
me
offline.
I
think
you
can
ping
bootcash
also
because
we
did
the
original
ap
combat
tooling.
We
can
migrate
to.
C
This
one,
it
will
save
us
a
lot
of
time
in
the
protein
while
having
greener,
ci
checks.
B
All
right,
I
think
that's
it
for
comments.
We
can
endure
early,
see
you
all
next
week.