►
From YouTube: 2022-12-14 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
A
All
right
so
Dan
asked
me
to
run
the
sick
meeting
today,
so
I
will
give
that
a
give
that
a
shot.
Let's
see,
let's
wait
for
a
bit
if
someone
else
joins
and
then
I
guess
we
can
get
started.
D
No
I'm
I'm,
basically
new
I
lurked
last
meeting
okay
lurking
when
I'm
able.
A
Good,
let's
see.
A
Foreign-
let's
see
oh
yeah,
that's
better!
All
right!
Then,
let's
get
started.
The
first
point
of
today's
meeting
is
PR's
in
need
of
reviews.
These
we
already
talked
about
this
last
week.
I
think
I
wasn't
here
for
that
one,
but
one
of
those
got
merged.
This
was
this
active
context
in
the
default
node
Tracer,
and
there
are
two
more
that
are
still
in
need
of
reviews.
The
first
one
is
from
then
the
performance
clock
drift
PR
that
yeah
there's
a
few
Alternatives
out
there
of
those.
A
If
that
one
do
you
want
to
say
a
few
words
about
that
then
yeah.
C
This
one
actually
has
merge
conflicts
right
now.
I
have
not
had
time
to
work
on
this
since
last
week,
but
I'm
going
to
add
the
the
required
changes
to
the
fetch
instrumentation,
also
in
the
same
PR,
because
this
PR
does
break
the
fetch
instrumentation,
but
the
fetch
instrumentation
needs
to
be
fixed
anyways.
So
it
should
be
a
simple
change.
I'll
be
updating
that
this
week,
hopefully.
A
All
right,
thank
you,
so
there's
Alternatives
out
there
as
well
so
is:
did
we
settle
on
on
this
one
or
I.
C
Think
I'm
happier
with
this
one,
the
other
one
I
guess-
is
still
open.
Maybe
I
should
close
it.
I
I
kept
them
both
open
to
get
opinions
from
people
on
which
they
preferred
and
nobody
really
voiced
their
opinion,
except
for
T2.
So
I
guess
we're
just
gonna
go
with
the
one
I
prefer,
which
is
the
simpler
one.
So
all.
A
Right
sounds
like
a
plan.
Thank
you
and
if
there
are
no
comments
from
someone
else,
then
I
guess
we
can
move
on
to
the
next
one.
This
one
is
about
sync
resources
with
some
research,
asynchronously
I
have
to
admit.
I
haven't
really
looked
into
that
in
detail.
I'm,
not
sure.
If
the
author
of
that
one
is
on
the
car
today
think
no.
C
I
think
now-
and
it
looks
like
two
maintainers
have
requested
changes.
I
have
also
not
looked
at
this
PR
in
quite
a
while,
but
Amir
you're
on
the
call.
Do
you
want
to
give
a
quick
summary
on
why
you
and
on
what
the
issue
is?
Is
it
a
fundamental
issue
with
this
PR,
or
is
it
just
something
that
they
did
wrong?
It's.
E
Not
fundamental,
there's
just
a
few
things
that
are
not
according
to
the
spec
that
should
be
changed
a
few
places
in
the
readme's
that
should
be
updated.
There
is
one
thing
that
I
want
opinions
on
those
radio
that
flauna
also
commented.
Do
you
think
it's
safe
in
the
possesso
to
assume
that
there
is
only
one
resource?
A
E
C
Then
oh
yeah,
yeah
now
I
shoot
you
man
I.
Remember
there
was
discussion
on
the
spec
a
while
ago
about
this
and
I
think
the
resolution
was
that
you're
expected
to
have
like
one
one
Tracer,
processor
and
exporter
pipeline,
like
those
are
all
sort
of
tightly
coupled
and
they're,
not
expected
to
be
shared.
So
if
you
have
two
tracers
I
think
you're
supposed
to
create
a
separate
export
pipeline,
but
there
is
nowhere
where
that's
enforced.
C
F
C
Yeah
resource
should
not
change
I.
Think
now,
there's
been
a
part
of
some
working
group
work
that
has
been
trying
to
change
that.
So
that's
probably.
C
Right
as
far
as
I
know
nothing
in
the
spec
yet,
but
we
probably
should
keep
it
in
mind.
We
don't
want
to
implement
anything
now.
That
would
be
a
problem
if
it
is
specified
later
that
resources
can
be
changed.
Foreign.
C
I
will
look
into
the
the
spec
that
I
referred
to
I,
honestly,
just
don't
remember
it
that
well,
it's
been
a
while,
since
I
looked
into
that
part
of
the
spec,
so
I'll
look
into
that
and
comment
on
this.
A
All
right,
thank
you
right,
so
that
should
be
it
for
for
that
PR
then.
The
next
point
is
Matt.
You
added
this
one.
Do
you
want
to
say
a
few
words
about
that
checking
in
on
the
status
of
this
PR
right
here,
I
think
then
you
open
this
one.
Some
time
ago.
C
Yeah
I
opened
it
a
while
ago,
I
actually
just
resolved
the
merge
conflict
a
minute
ago.
C
There
are
a
couple
of
comments
on
here,
nothing
to
nothing
too
fundamental
I'll
try
to
update
this
and
get
this
released
this
afternoon,
since
other
people
are
waiting
on
it.
I
had
honestly
just
I,
don't
know
forgotten
is
the
right
word
but
had
other
priorities,
but
this
is
a
small
thing
that
I'd
like
to
get
in
and
is
important
to
other
people,
so
I
guess
the
the
status
update
is
that
I
haven't
been
working
on
this
for
a
while,
but
I
will
make
sure
to
finish
this
today.
D
C
Yep,
it's
it's
not
a
big
PR,
it's
already
reviewed
by
the
component
donors
and
yeah.
Honestly
I
should
have
completed
this
a
while
ago,
so
I'll
make
sure
to
do
it.
A
Right,
thank
you
and
then
the
next
one
is
also
then.
The
country
release
automation.
C
Yeah,
no,
actually
something
that
I
think
people
are
probably
sick
of
me.
Hearing
it's
sick
of
hearing
me
say
that
is
not
done
yet,
but
my
update
this
week
is
that
there
is
no
update
here
right
now.
I
did
work
on
it
a
little
bit
over
the
last
week.
My
new
version
of
the
release.
C
Automation
is
also
running
into
rate,
limiting
issues,
so
I
am
trying
to
figure
out
ways
around
that,
but
right
now
we're
creating
at
least
a
tag
and
a
release
per
component,
which
is
how
we
track
the
versions
separately
per
component
and
when
we
have
large
releases
of
all
the
components
that
alone
gets
you
very
close
to
the
rate
limit,
so
I'm
trying
to
to
figure
out
what
we
can
do
about
that
I
did
reach
back
out
to
the
GitHub
contact
to
find
out
whether
that
they
said
that
they
were
going
to
look
into
raising
the
rate
limit,
but
I
never
heard
back
from
them.
C
So
I
sent
them
another
message
and
still
have
not
heard
back,
but
yeah
I
I
really
have
not
changed
much
here
in
the
last
week,
so
I
am
still
working
on
it,
but
it's
just
ongoing.
A
All
right,
thank
you
for
the
the
info
on
that
one,
and
also
thank
you
for
working
on
this.
This
country,
release
automation,
is
a
pain
I
think
for
for
many.
E
A
There
right
the
next
one
is
Matt's
topic
here:
the
exponential
histogram.
D
Yeah
I
just
wanted
to
give
a
brief
update.
I've
been
quietly
working
on
an
implementation
since
around
kubecon
and
holidays
in
between
all
that,
but
I
I
have.
D
I'm
exporting
data,
fine
I
I
was
going
to
spend
a
little
bit
more
time
like
validating
the
implementation
and
cleaning
things
up,
but
I'll
be
opening
a
PR
soon,
probably
before
the
next
meeting.
D
It
is
a
lot
of
work,
so
I
think
yeah,
I
I
will
be
flexible
about
how
we
want
to
integrate
it
and
how
we
want
to
kind
of
go
through
it
all
so,
like
I,
think,
probably
it
some
sort
of
walkthrough
would
be
warranted,
and
if
we
want
to
try
to
like
chop
it
up
into
smaller
chunks,
I
would
be
open
to
to
any
of
that.
It
is
yeah.
It's
all
quite
complicated
and
I
think
you
know.
D
Reading
the
spec
helps
to
be
able
to
review
this
stuff,
but
I
I,
don't
know
I.
Think
I
think
there's
a
lot
to
understand.
Ultimately
so
I'm
not
sure
what
what
the
best
way
to
do
that
is,
but
I
think
I
can
at
least
start
with
a
walk
through
and
see
like
what
what
questions
people
have
and
yeah
that's
really.
D
My
update
is
that
things
are
coming
together
and
there
will
be
something
to
look
at
soon
and
we
will
figure
out
the
best
way
to
kind
of
work
on
reviewing
and
integrating
it.
B
Okay,
do
you
think
if
you
want
to
do
a
walk
through,
do.
C
You
think
we're
better
off
doing
that
next
week
or
waiting
until
the
new
year
Wendy.
What
do
you
think
is
a
a
good
timing
for
that,
like
the
these
meetings
have
been
short
in
the
last
few
weeks,
so
I
think
utilizing
the
existing
time
slot
that
we
already
have,
for
this
is
probably
a
good
idea,
but
doing
it
between
Christmas
and
New.
Year
is
probably
not
a
good
idea.
C
D
Yeah
good
question:
how
about
I,
if
I
have
something
prepared
next
week?
I
will
give
it
next
week.
If
it's
too
rough
to
like
you
know,
make
it
worth
anybody's
time,
then
I
think
we
just
wait
until
the
new
year.
Does
that
sound
like
a
reasonable
plan.
B
C
C
The
the
maintainer
who
does
most
of
the
metrics
work,
unfortunately,
is
extremely
unlikely
to
be
able
to
join
since
he's
in
China,
but
these
meetings
are
recorded,
so
I'll
make
sure
to
have
him
watch
the
recording
too,
when
we
do
it
and
I
will
read
up
on
the
exponential
histograms
spec
I'm,
already
mostly
familiar
with
it,
but
I'll
make
sure
that
I'm
that
it's
fresh
in
my
mind
before
we
do
that
cool.
A
All
right,
thank
you
for
the
update
and
also
thank
you
for
working
on
this
day.
I
know
a
lot
of
people
are
looking
forward
to
the
exponential
histogram
and
I'm,
also
looking
forward
to
seeing
seeing
what
you
came
up
with
right.
So
the
next
one
is
nav,
with
an
update
about
the
sandbox
yeah.
F
So
I
was
working
nicely
to
get
the
sandbox
up
and
running
for
this
year,
but
I
hit
a
couple
of
roadblocks
last
week
as
part
of
the
merging
from
the
staging
repo
into
the
main
sorry,
the
staging
Branch
to
the
main
branch
I'm
just
trying
to
remove
the
stuff
that
I
didn't
want
to
bring
over,
but
that's
causing
merge
conflicts
after
the
first
one.
The
first
one
works
perfectly
subsequent
ones
go,
but
you've
already
deleted
this.
F
So
I
you're
trying
to
work
around
that
I
may
just
end
up
saying:
okay,
the
entire
Auto
merge
folder
comes
into
main
as
well,
and
that
would
resolve
it.
But
some
internal
stuff
came
up
and
I've
been
sidetracked
for
the
last
couple
of
days.
So
that's
going
to
delay
the
sandbox
until
next
year,
as
I'm
out
for
the
next
three
weeks,
not
back
till
January
9..
So.
A
All
right,
thank
you
for
for
the
update,
so
the
next
one
is
Martin
with
the
logs
SDK
that
is
blocked
on
some
changes.
Do
you
want
to
talk
about
this
real,
quick.
G
Yeah
so
I
have
the
draft
logs
logs
SDK,
open
and
PR
open,
and
there
is
also
a
person
who
opened
a
PR
with
some
changes
to
the
events
logs
events
API.
What
I
didn't
realize
until
recently
is
that
the
apis
spec
changed
like
in
November.
G
Like
the
events,
the
events
API
was
split
from
the
logs
API
and
so
the
implementation
of
the
logs
API
that
we
have
currently
has
both
the
logs
and
and
events
in
the
same
in
the
same
package
and
I
guess,
I
I
talked
to
I
talked
to
Jack
Jack
Burke
for
a
little
bit
who
attends
the
logs
logsig,
and
he
said
there
is
a
chance
that
the
events
API
might
be
changing
again,
so
I'm
kind
of
trying
to
decide
right
now
if
it
makes
sense
to
continue
on
the
SDK
or
if,
if
I
should
pause-
and
you
know
refactor
the
the
API
package
so
I,
that's
my
update
for
now,
like
I'm,
not
really
sure
I
feel
like
I'm
a
little
bit
blocked,
but
my
plan
is
to
attend
the
logsig
and
hopefully
get
some
some
more
clarification
on
this
guidance.
F
Yeah
one
of
the
big
changes
that's
being
discussed
at
the
moment
is
dropping
the
domain
so
and
then
potentially
merging
that
the
name.
So
at
the
moment
the
domain
is
defined
as
being
a
resource,
I
think
but
yeah
it's
looking
at
that's
going
to
go,
which
is
where
I
think
the
change
in
the
API
is
coming
from.
Yeah.
G
And
the
change
the
change
that
I,
the
recent
changes
that
I'm
referring
to
nav
is
the
the
split
of
the
events
API,
which.
G
Yeah-
and
it
was
it's-
it's
basically
just
yeah
like
a
like
a
you
know
like
synthetic
sugar
on
top
of
the
logger
API
yeah.
At
this
point,
so
yeah
I
mean
there's
still
there's
still.
Work
could
still
continue
on
on
the
on
the
like.
Just
the
logs
part,
so
maybe
like
one
path
forward,
would
be
to
remove
the
events,
even
events
API
for
now
and
just
finish,
the
logs
part.
G
Yeah
all
the
way
all
the
way
through,
but
you
know
like
I,
come
from
the
client-side
group
also
so
like
our
kind
of
incentive
on
working
on
this
was
to
generate
events.
So,
but
I
can
you
know
that's
one
path
forward,
potentially
just
to
finish
the
the
logger
SDK
and
the
the
exporter.
F
Yeah
I
think
in
last
week's
log
meeting
affected
there
was
a
proposal
to
kill
the
bugs
API
completely,
but
that
is
now
being
kept
as
of
last
week
unless
that's
changed
again.
F
Okay,
so
yeah
that
that
Pilgrim
didn't
see
a
need
for
the
for
the
AP
of
the
logger
Pender
API,
so
yeah
we
probably
could
continue
with
that
or
someone
people
can
still
keep
working
on
that
portion,
but
yeah
the
event
stuff
is
still
open.
G
Yeah,
so,
okay
anyway,
so
I'm
I'll
I'll
get
some
some
more
more
feedback
over
in
the
log
blog
Sig
and
we'll
continue
as
based
on
that.
A
All
right,
thank
you
for
the
update,
I,
think
generally.
Moving
moving
forward
with
just
the
logs
would
be
would
be
a
good
option,
also
I
think,
since
we
are
clearly
marked
as
experimental,
it
would
also
be
possible
to
move
ahead
with
with
logs
and
events
and
then
split
that
up
afterwards.
We
do
not
give
any
stability
guarantees
on
the
packages
anyway,
so.
F
A
Yeah
so
yeah
right.
G
C
Yeah,
if
we're
going
to
I
I,
think
there's
no
point
in
implementing
an
SDK
against
an
API
that
we
know
is
already
out
of
date.
So
updating
the
API
first
makes
sense.
C
C
Is
the
API
spec
at
a
point
right
now,
where
it's
a
good
idea
to
implement
it,
or
is
it
likely
to
change
again
real
quick?
Should
we
just
wait
exactly
yeah,
so
I
think
we
do
the
API
before
the
SDK
and
the
question
is:
is
now
a
good
time
to
do
the
API,
or
should
we
do
it
in
January
or
something
like
that.
C
G
A
A
All
right,
then,
if
there
are
no
more
topics,
I
guess
we
can
move
on
to
the
back
triage
right.
So
on
the
Quarry
Bill.
We
have
this
one
right
here
about
weka
threads,
not
being
instrumented
using
burka
data.
A
That
looks
like
this
person
is
having
problems
with
One
Way
working
and
the
other,
not
working
I'm,
not
sure.
If
we,
if,
if
we
even
support
worker
threads,
does
anybody
on
the
car
know
that
if,
if
there
is
something
that
we
are.
C
It's
not
something
that
we
need.
It's
not
something
that
we
explicitly
say
we
support,
and
there
is,
as
far
as
I
know
no
automated
testing
for
it.
But
that
said,
I
would
have
expected
it
to
work.
Yeah.
C
That's
too
many
workers.
This
is
no
Jazz
worker
threads
okay,
so
that
what
we
test
with
web
workers
is
just
testing
that
open
Telemetry
itself
Works
in
a
web
worker,
if
you
instantiate
it
in
a
web
worker
I
think
this
is
a
an
application.
Instrumented
with
open
Telemetry
starts
to
thread,
and
in
that
thread,
does
a
task
and
they're
expecting
that
task
to
be
instrumented.
C
C
This
to
me,
I,
don't
know
if
this
will
be
easy
to
support,
but
you
can
leave
the
triage
label.
I
I'm,
not
I'm,
not
convinced
that
this
is
a
bug.
It
may
be
a
feature
request,
hiding
as
a
bug.
A
Yeah
that
that
definitely
could
be
I
just
remember.
For
some
reason,
I
I
had
a
look
earlier
at
some
of
the
some
of
our
documentation
and
the
guidelines
for
developing
and
I
think
for
I.
Some
time
ago,
I
saw
some
some
statement
that
these
were
not
specifically
supported,
but
it
might
have
been
into
in
some
Google
Docs
document
that
we
had
for
developing
metrics.
C
A
Okay,
thank
you,
then,
moving
on
that
is
a
person
having
a
problem
with
instrumentation,
not
working
with
typescript
paths.
Yeah.
C
We
already
we
already
discussed
this
one.
Actually,
it's
already
Ascent
right.
A
Also
so
is.
C
This
is
not
new.
We
requested.
A
Yeah
that
should
be
it
for
this
meeting
right
then,
if
no
one
has
any
topics
left,
then
thank
you
and
see
you
next
week.
Thank.