►
From YouTube: 2023-02-06 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
A
B
D
D
D
B
Yeah,
basically,
there's
a
PR
for
doing
the
release.
Please
review
that
it
has
a
pair
of
reviews
already.
We
also
as
part
of
doing
the
release.
We
need
to
update
the
schema
by
creating
a
new
schema
file,
for
you
know
that
can
be
later
posted
to
the
website
as
well.
So
please
review
that
Tyler
I
answered
your
question.
B
Let's
follow
up
with
Lino
on
that
one,
and
please
everybody
review
that.
Thank
you.
The
other
one
is
HTTP
semcom
yeah,
that's
not
mine!.
D
E
B
Yeah,
that's
the
one
that
was
preventing
well,
it's
still
preventing
technically
going
making
OTL
PJs
unstable.
Basically,
it
means
that
empty
or
missing,
trace
and
Spanish
means
that
the
data
that
is
valid
well
I
think
it's
good
to
people
who
were
not
aware
of
this
change.
You
know
TLP
specifically
to
be
aware
of
that
now,
especially
because
we
would
like
to
release
it.
Will
it's
very
possible
that
this
release
will
include
TLP
Json
as
a
stable
item.
E
D
E
Was
having
unmute
issues,
you'd
mentioned
the
log
Sig
I
don't
feel
super
comfortable,
maybe
like
representing
them
entirely,
but
there
is
an
effort
going
on,
as
some
may
know,
to
bring
this
to
the
community.
Bring
the
idea
of
of
marking
the
log
SDK
and
API,
stable
and
I
will
find
the
issue
right
now
and
put
it
in.
E
But
I
do
want
to
have
another
discussion
with
the
log
group,
because
I
know
that
tigrant
I
think
has
an
idea
of
how
he
wants
to
approach
it,
but
maybe,
as
a
as
a
teaser
I'll
just
share
that
issue
in
the
agenda.
Awesome
thanks.
D
E
That'll
exclude
the
event
stuff,
so
the
the
event
in
the
logging
API
was
split
so
that
that
could
that
could
occur.
E
D
E
D
F
Oh
they're,
going
yeah
we
two
weeks
ago
now
released
a
metrics
API
and
a
metrics
SDK.
The
metric
API
work
was
done
to
bring
in
some
alignment
with
the
specification.
We
think
that
we
are
compliant
with
the
specification
at
this
point,
but
we
wanted
to
get
some
TC
member
to
review
that
API.
F
Just
to
make
sure
that
we
are
so
that
we
can
move
forward.
The
goal
then
would
then
be
to
move
into
release
candidate
cycles
for
the
metrics
API.
F
One
thing
that
we
have
identified,
though,
is
that
our
no
op
meter
doesn't
actually
do
any
logging
for
invalid
names
and
that
kind
of
thing
which
I
think
after
bringing
it
to
the
specification
it
doesn't
sound
like
is
something
we
want
to
do
in
the
land.
So
there
also
a
specification
work
to
try
to
fix
that
and
there's
a
link
to
PR
here
that
we
would
love
anybody's
review
on
that
to
try
to
resolve
it.
F
So
our
no
op
implementation
doesn't
do
things
and
then,
outside
of
that,
our
next
steps
for
the
metrics
SDK
are
doing
a
similar
internal
review
so
that
we
can
ensure
compliance
and
then,
hopefully,
more
move
forward.
To
that
awesome.
D
Great
Carlos,
maybe
help
me
remember,
to
bring
this
TC
review
request
to
the
next
TC
meeting.
D
If
someone
doesn't
grab
it
by
then
should
someone
should
get
aside
there,
the
Duke
glad
to
see
that
going
GA?
That's
awesome.
H
D
H
Yeah,
so
we
had
a
release:
a
new
release,
1.8.2
that
had
a
few
metrics
changes.
Basically,
we
were
not
supporting
custom
aggregation.
Only
default
aggregation
was
supported
for
that
that
support
was
added
and
they
were
minor
building
improvements
and
also
there
is
an
ongoing
log.
Sdk
changes
as
well
as
picks
I,
think
it
will
take
probably
I
think
two
to
three
weeks
to
complete
the
implementation
for
that,
and
we
are
planning
to
have
one
change
right
now.
We
are
I
mean
for
the
pr
math
policy.
We
have
two
mandatory
approvals.
H
One
of
them
has
should
be
from
the
different
company
for
for
the
original
author
of
The
PR,
but
I
think
we
are
planning
to
change
it.
We
have
already
discussed
in
our
Sig
meeting.
We
have
a
shortage
of
active
approvers
and
not
all
the
approvers
have
enough
knowledge
of
all
the
areas
like
for
Matrix
and
I.
Think
we
don't
have
enough
keywords.
You
know
you
know
all
inside
out,
so
I
think
we
plan
to
change
this.
So
just
wanted
to
call
out
here.
Yeah.
H
I
H
Yeah,
so
there
are
two
people
from
Microsoft
one
from
Oracle
and
one
is
individual
contributor
and
there
is
one
person
from
China
who's
working.
So
the
only
thing
is
that
not
everybody
is
has
expertise
on
all
the
different
components.
So
they
are
not.
They
cannot
review
everything
so
like
for
thematics.
Only
one
person
is
dedicated
approver.
Who
knows
all
that
all
the
videos
so
I
think
it.
A
H
Overall,
it
delays
the
I
mean
the
pr
circuit
most
so
yeah.
It
is
not
good
too.
D
Maybe
just
a
reminder
for
people
on
their
call
current
maintainers.
If
you
want
to
poke
your
network
to
see
if
there
are
people
at
your
company
or
people,
you
know,
who'd
be
willing
to
contribute
to
C
plus
plus
sounds
like
we
need
to
to
do
a
bigger
push
to
try
to
get
more
people.
A
D
D
Here's
one
summary,
but
we
would
like.
D
As
these
get
published,
we
would
like
feedback
from
the
community
and
for
maintainers
on
the
call
when
we
get
feedback.
Let
there's
two
kinds
of
sessions.
There's
sessions
where
it's
just
kind
of
like
a
general
q
a
and
there
are
end
user
sessions
where
it's
kind
of
like
a
deep
dive
interview
with
a
particular
end
user
organization,
and
we
do
get
a
lot
of
feedback
when
we
do
those
deep
Dives.
We
don't
totally
know
the
best
way
to
give
out
that
feedback
to
maintainers.
D
Some
of
it
is
like
General,
open,
Telemetry
feedback
like
we
wish.
There
were
more
docs,
but
there
are
often
like
specific
pieces
of
feedback.
For
you
know,
particular
implementations
I
was
suggesting
that
it
all
get
hyped
up
and
then
we
ping
different
working
groups
in
their
slack
channels.
D
E
E
Maybe
Carter
you
can
do
a
quick
report
back
there.
J
Yeah
sure
so
we're
making
steady
progress
only
getting
the
spec
updated.
We
have
subject
matter
experts
from
AWS,
Azure
and
Google
kind
of
providing
feedback
on
generic
functions
terms,
so
we're
trying
to
unify
that
schema
into
something
consistent
for
open,
Telemetry
and
then
we're
doing
kind
of
a
current
layer
assessment
for
lambdas
as
well,
because
the
different
language
implementations
Behavior
varies
by
language,
so
we're
trying
to
get
a
sense
of
what
languages
do
you
want
and
why
and
so
we'll
be
looking
to
kind
of
fix
those
going
forward
too.
D
D
Let
me
share
my
screen:
okie
doke
and
I.
Always
love
help
triaging
this,
but
if
this
is
totally
boring
to
you,
you
don't
have
to
stay.
For
this
part,
let's
see
picking
up
from
where
we
last
got
done.
Triaging
export
span
context
is
remote
in
otlp
I
thought
we
had
actually
looked
at
this
one
yeah.
B
E
D
Yeah
I
think
this
is
a
complicated
one
that
isn't
isn't
on
a
roadmap,
so
I'm
just
gonna
mark
it
as
triage.
So
I'm
gonna
keep
coming
back
to
it,
get
out
of
here.
Zoom
Chrome
you
take
up
so
much
screen
real
estate.
D
Instrumentation
layers
and
suppressing
duplicates,
this
is
part
of
our
related
to
our
semantic
convention
work.
D
This
is
actually
implemented,
I
believe
in
Java,
but
the
idea
here
is
you
can
sometimes
get
a
several
layers
of
instrumentation
reporting
the
same
thing,
so
you
have
Java
spring
plus
some
kind
of
java,
HTTP
Library,
plus
something
under
the
hood
of
that
library
and
they're
all
instrumented
and
they're
all
producing
an
HTTP
span,
and
this
is
a
proposal
for
how
to
automatically
squash
those
duplicates.
D
I
do
believe
this
is
on
a
road
map
and
maybe
related
to
the
new
HTTP
symante
convention
working
group
that
has
popped
up.
I
could
see
that
group
wanting
to
chew
through
this
so
I'm
just
going
to
add.
E
D
D
Calmer
encoding
just
going
to
quickly
mark
this
as
triaged.
This
is
actually
making
a
lot
of
progress.
I'm
really
excited
about
this
work
for
people
who
don't
know.
This
is
a
much
more
efficient
wire
protocol
for
otlp
that
dramatically
reduces
egress
costs.
When
you
have
a
lot
of
data
you're
trying
to
get
out.
D
So
the
idea
with
this
one
this
is
from
long
ago,
I
believe
this
is
also
implemented
in
Java-
is
to
give
end
users
instrumentation
writers,
like
higher
level
abstractions,
to
help
ensure
that
you
actually
Implement,
say
the
HTTP
semantic
conventions.
Correctly,
we've
been
kicking
around
the
idea
of
giving
people
basically
helpers
rather
than
having
them,
have
to
basically
like
open
up
the
spec
and
try
to
figure
out
exactly
what
they're
supposed
to
be
doing.
Could
we
actually
give
people
some
code?
This
was
an
old
Java
proposal
for
doing
this.
D
I'm
curious
for
maintainers
on
the
call.
Is
there
interest
in
working
on
this
kind
of
thing
in
other
languages.
B
K
Yeah
yeah,
it's
it's
implemented
in
Java.
Another
key
part
of
this
is
unifying
metrics
and
traces
so
that
you
know
the
instrumentation
API
just
says.
Like
start
operation,
you
know
start
and
end
you
pass
in
the
attributes
and
under
the
hood,
it
creates
based
on
how
you've
registered
configured
that
instrument
or
it'll
either
create
spans
and
metrics
or
just
spans,
and
all
of
our
Java
instrumentation
is
built
on
top
of
this
instrumentation
API.
B
D
Yeah
I
think
it's
worth
looking
at.
I.
Think
that
the
question
is:
do
that,
whether
or
not
you
know
people
should
do
this
in
Java
I!
Think
that's
fine,
but
should
do
we
want
something
like
this,
as
actually
like
part
of
the
spec
and
implemented
in
other
languages,
it
does
kind
of
seem
like
if
it
goes
everywhere,
we'd
like
to
spec
it
out
a
little
bit.
D
If
I
recall
the
only
issue
with
this
particular
proposal
was
it
felt
very
java-ish,
The,
Way,
It,
Was,
Written,
so
I
think
there
were
questions
about.
You
know
what
we
would
actually
put
in
the
spec
for
languages
like
go,
for
example,
to
implement
something
similar
I,
don't
I,
don't
know
how
much
of
a
priority
this
is.
We.
L
Have
something
similar
in
JavaScript
I
would
say
it
doesn't
match
this
specification
at
all,
but
it
solves
a
similar
problem,
but
my
question
would
be:
are
there
any
language
maintainers
that
feel
like
this
is
really
a
problem
in
their
language
right
now,
so
Java
has
already
implemented
a
Helper
and
JavaScript
has
already
implemented
a
helper
I.
Think
Ruby
has
already
implemented
some
sort
of
helper.
It
seems
like
at
this
point
specifying
it
would
just
mean
everybody
has
to
rewrite
their
helpers
so
that
they're
all
the
same.
L
It
is
this
a
actually
a
big
pain
point
in
any
of
the
existing
sigs
and
is:
would
it
better?
Is
this
better
solved
at
the
Sig
level.
L
E
D
Yeah
in
the
past
I've
gotten
kind
of
nervous
when
you
know
something
comes
in
that
ends
up
being
like
basically,
a
big
part
of
the
API
in
a
language
that
isn't
part
of
the
spec
I,
don't
know
how
much
it
matters
I
think
you
know
the
the
only
way
it
matters
is
less
about
cross-language,
stuff
and
more
just
making
sure
if
this
is
going
out
to
the
public
in
a
language
that
you
know
it's
going
to
be
backwards
compatible
right
because
if
we
hand
out
helpers
for
instrumentation
and
then
this
is
going
into
like
third
party
code
right
like
open
source,
libraries
or
stuff
like
that,
and
then
a
breaking
change
gets
put
out
to
these
helpers.
M
So
yeah
and
people
coming
together
can
head
that
off.
If
designing
the
API
around,
that
people
have
already
experienced
probably
problems
with
their
rappers
and
come
up
with
what
it
needs
and
what
their
users
need,
and
those
are
probably
similar
across
sigs.
So
it.
D
D
Yeah
I
think
that's
my
thing.
I,
don't
know
that
I
want
to
say
everyone
has
to
do
it
the
same
way
in
every
language,
but
more
just
if
we
start
it
I
mean.
Maybe
it's
just
just
having
some
trust
in
the
maintainers
to
know
that
that,
if
you
put
something
like
this
out
there,
you,
you
really
do
have
to
support
it,
and
you
can't
make
breaking
changes
to
it.
D
E
M
M
This
was
taken
up
by
someone.
I
would
certainly
take
part
in
The,
erlang
Elixir
Sig
would
be
interested,
I,
don't
think
I
can
head
it
up,
but
I
know
I
would
definitely
help
out.
D
B
Yeah
also
I
think
yeah
I
think
that
also,
even
though
Biden
wasn't
mentioned
as
one
of
the
languages
that
have
these,
since
they
are
trying
to
have
an
instrumentation
agent,
this
could
be
useful.
You
know
if
it
was
useful
for
Java.
D
Yeah,
where
I
I
think
I
want
to
keep
track
of
this
is
as
we're
trying
to
stabilize
our
semantic
conventions.
It
does
mean
in
every
language
we're
going
to
be
doing
like
passes
through
the
instrumentation
and
updating
a
lot
of
it
and
I
think
a
lot
of
it
probably
doesn't
have
metrics
yet
and
we'll
want
to
have
metrics
get
added
to
it,
among
other
things.
D
D
D
It
also
seems
potentially
potentially
helpful
to
keep
instrumentation
up
to
date
when
the
spec
changes,
or
at
least
potentially
helpful
to
keep
track
of
you
know,
what's
implemented
what,
but
so
I'm
personally
just
going
to
try
to
remember
that
this
exists
and
I
would
just
say,
yeah
to
maintainers.
If
you
get
into
a
cycle
where
you're
starting
to
do
a
sweep
through
contrived
and
updating
instrumentation
to
to
think
about
this,
this
Otep
to
think
about
the
kind
of
helpers
you're
working
on.
D
D
All
right
moving
on
Define
resource
semantic
convention,
stability
and
justification,
this
is
I
think
we
can
bring
I'll
bring
this
one
up
in
the
semantic
convention
meeting.
That's
happening
right
after
this
and
ask
Josh
sirrith
what
what
he
wants.
I
E
C
E
D
D
This
looks
very
similar,
specified
mechanism
for
users
of
resource
to
interact
with
resource
leveraging.
Telemetry
schema
version
for
stable,
API,
exportedness
K
of
excess
to
stable
resource
names.
D
A
K
G
G
Sean
was
working
on
one
in
the
collector
as
a
as
a
processor
but
I
believe.
That's
still
work
in
progress,
I'm,
not
aware
of
any
happening
in
any
languages.
Okay,.
E
D
To
label
this
guy
I
do
think
this
is
still
relevant
but
I'll.
Let
Josh
close
it
if
it's
not,
but
if
it
is,
then
it's
P1.
D
This
Otep
proposes
the
ability
to
configure
the
level
detail
of
span
creation
from
open,
Telemetry
instrumentation
as
an
alternative
to
sampling
for
reducing
the
performance
impact
as
a
matter
of
balancing
performance
and
expressiveness
of
traces.
The
intention
of
the
sotep,
mostly
as
a
basis
for
further
discussion
around
the
subject,
the
benefits
disadvantages.
Pursuing
such
functionalities
is
basically
like
log
levels
for
traces.
D
D
B
A
F
You're
I
think
you're
right,
I
wouldn't
recommend
working
on
it
and
I
I,
don't
know,
I
think
leaving
things
open
in
a
state
that,
like
we're
not
actually
going
to
work
on
it,
can
either
frustrated
or
can
communicate
that
like
we're
still
thinking
about
it,
but
I
think
we
just
say,
like
you
know,
we're
closing
it
has
not
planned
work.
I
think
that's
helpful
in
communicating
it
personally.
I
know
also
that
you.
D
Yeah
I
think
that
makes
sense,
I
think,
maybe
just
in
this
past
right
now,
I
don't
want
to
come
in
and
close
things
I
think
when
we
start
getting
things
on
the
actual
like
road
map,
but
I
totally
agree
with
you.
We
should
come
back
and
say
like
Hey,
we're
we're
totally
not
going
to
do
this,
so
we're
just
going
to
close
it
for
now.
If,
if.
G
D
So
what
I've
been
doing
is
just
marking
those
issues
is
triaged
and
not
giving
them
a
priority
kind
of
for
the
same
reason:
I
don't
want
to
right
now
give
things
like
we
don't
care
tag,
but
basically
by
not
giving
it
a
priority.
We're
we're
essentially
saying
that
so
everything
that's
in
here,
that's
marked
as
triaged,
but
doesn't
have
a
priority
attached.
D
Something
that,
as
far
as
I
can
tell
we
have
no
plans
to
to
work
on,
and
it's
not
it's
not
on
a
roadmap.
So.
D
But
I'm
totally
open
to
to
figuring
out
how
we
actually
handle
these
because
I
kind
of
agree
that
you
know
we
should,
unless
there
are
people
actively
discussing
this
and
like
want
to
keep
working
on
it,
even
though
it's
not
on
our
roadmap,
like
we
should
probably
close
these
ones.
That
haven't
been
touched
in
like
a
year
or
two
and
just
say
you
know,
come
back
later.
D
E
D
You
know,
dig
the
old
one
up,
but
I
don't
know
how
valuable
it
is
to
leave
like
good
ideas
that
we
don't
plan
on
doing
anything
about
right
now
like
open,
but
that's
why
I'm
not
closing
them
quite
yet
because,
like
maybe
maybe
we
do
want
to
leave
them
open,
but
have
some
kind
of
tag
that
we
can
filter
them
out
with.
E
D
L
G
Yeah
cloudwatch
metric
streams
is
an
example
of
this.
Where
we
can
emit
otlp
over
can
use
this
fire
host.
Okay,.
D
But
it
looks
like
it's
just
been
stalled
out
for
a
really
long
time,
so
I
think
I'm
just
going
to
leave
it
in
this
state.
For
now
it
doesn't
seem
to
be
something:
that's
that's
on
a
roadmap,
but
does
seem
useful
for
some
definition
of
useful.
E
G
A
F
Know
I
can't
quite
remember:
I
thought
there
was
like
a
Java
metric
system
that
did
this
where
there's
like
a
text
type-
and
this
is
probably
just
trying
to
have
a
parody
there,
but
it
may
be
that
we
just
handle
this
in
a
different
way.
D
So
we
could
ask
some
googlers
what
they
use
this
for,
but
no
one
in
our
community
has
cared
too
much
about
this,
so
I'm
inclined
to
to
think
that
it's
it's
not
a
huge
priority,
given
that
metrics
has
gone
through
quite
a
bit
of
change
since
2020.
I.
L
Think
some
people
care
a
lot
about
writable
resources
which
solves
the
same
problem.
Mm-Hmm
I
wouldn't
say
that
that's
this
Otep,
though.
D
And
we're
we're
really
getting
into
the
old
stuff
at
this
point,
so
I
feel
like
probably
everything
in
here
is
probably
something
that
should
be
closed
on
some
level
span
status,
Improvement
without
errors,
I,
don't
know
if
Matt's
on
the
call.
N
I
am
on
the
call,
but
this
is
a
blast
from
the
past.
I
need
to
read
it.
N
B
To
these
tattoos
error.
N
Yeah
I
feel
like
this
is
probably
predates
are,
are
current
span
status
scheme.
I
Send
also
predates
marking
it
as
stable,
I
think.
N
Right
so
I
think
we
can
go
ahead
and
close.
This
I
will
take
a
look
at
it
and
if,
for
some
reason,
I
have
an
epiphany
that
needs
to
be
reopened
I'll,
let
you
know.
D
K
D
D
F
I
think
this
one
might
still
be
relevant.
There's
still
questions
from
other,
especially
like
in
the
Java
world.
I
know
there
are
like
timer
metrics
in
I'm
blanking
on
the
name
of
the
metric
systems.
Right
now,
but
like
I,
think
this
is
still
an
active
question
that
I
hear
in
a
few
different
discussions
in
like
literal
GitHub
discussions
as
well
as
like,
like
slack
discussions
about
like
how
to
handle
the
timing
operations.
F
D
Yeah
I
mean
it
also,
maybe
seems
related
to
just
having
some
official
way
of
translating
spans
into
metrics
right,
because
that's
kind
of
what,
rather
than
putting
timers
in
everywhere,
can
you
just
have
a
processor
that
turns
you
spans
into
metrics.
So
maybe
that's
another
approach.
F
I
think
that's
that's
something
that's
important,
but
I
think
this
issue
is
more
around.
Like
you
know,
you
have
an
HTTP
duration
or
you
have
like
some
sort
of
thing.
That's
measuring
a
process
and
you
want
to
just
use
an
instrument
to
directly
measure.
It
I
think
was
what
the
the
intention
was
here.
It
wasn't
necessarily
around
the
span.
Translation,
although
I
think
that
it's
relevant
right.
D
I
mean
like
you,
you
do
have
I
mean
the
thing
that
I
think
they're
bringing
up
here
is
like
we
tend
to
sample
spans
and
like
do
things
with
them.
That
might
make
it
difficult
at
a
later
point
to
to
generate
a
metric
out
of
them.
So
we
should.
We
should
have
a
clear
story
for
people,
even
if
they
do
include
a
timer
for
some
things.
I
think
we
do
need
to
have
a
clear
story
for
how
you
go
about
turning
spams
into
metrics
and
what
are
like
some
potential
pitfalls
related
to
sampling.
D
L
There's
already
been
some
work
done
in
this
area
in
the
collector
I
believe
they
call
it
connectors
for
connecting
pipelines
of
different
Telemetry
types.
So
my
guess
is
it
doesn't
match
exactly
what
the
sotep
says.
Anyways.
G
E
D
D
I'm
tempted
to
just
just
tell
them
that
we're
we're
closing
this
yeah
I
mean.
B
A
E
G
G
Here
no,
there
was
one
from
Mark
64,
just
above
I
mean
this
was
September
of
2021,
but
if
the
spec
is
still
referring
to
this
PR,
it
should
probably
not.
E
G
Have
it's
it's
in
the
readme,
it's
in
the
repeat
now:
Otep
zero
one.
One
four
defines
how
the
trace
contact
should
be
recorded
in
logs
under
the
trace
context
and
Legacy
formats
heading.
E
G
D
E
I'm
gonna
go
ahead
and
close.
This
most
people
have.