►
From YouTube: 2022-12-07 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
B
I
had
a
busy
morning
and
not
much
time
to
prepare
an
agenda.
So
if
you
want
to
add
agenda
items
that
you
would
like
to
talk
about,
go
ahead,
otherwise
this
will
probably
be
a
fairly
short
meeting
this
week.
B
So
the
first
item
is
just
PR's
that
I
pulled
out
that
I
know
are
in
need
of
reviews.
I
think
all
of
them
are
are
fairly
mature,
PR's
that
are
just
waiting
on
feedback
from
people.
B
One
thing
that
I
did
want
to
talk
about
was
in
the
piarda
to
make
spans
resilient
to
clock
drift
T2.
You
did
mention
in
here
that
this
version
is
susceptible
to
drift
and
the
fetch
instrumentation,
which
is
if
you
do
not
provide
a
start
time,
but
you
do
provide
an
end
time.
B
I
think
that
this
is
probably
okay
and
I
think
that
we
should
update
the
fetch
instrumentation
to
either
provide
a
start
time
or
to
not
provide
an
HR
time
format
and
time,
because
that's
not
the
way
it
comes
back
from
the
performance
timer
or
from
the
performance.
Clock
anyways,
but
I
wanted
to
see
what
whether
you
thought
that
was
a
reasonable
solution
since
you've
been
looking
into
these
PRS
fairly
fairly
closely
and
I
saw
that
you
actually
applied
it
in
another
project.
Yeah.
C
I'm
going
to
have
that
project
branches
asking
every
other
day
if
when
it
needs
to
get
submerged
yeah
I,
think
last
week
we
also
talked
about
it
being
fine
to
switch
over
to
Performance
API
timings
for
fits
and
HSR
instrumentations.
B
C
A
B
Yeah
Legacy,
please
use
HR
time,
big
int,
instead
yeah,
okay,
so
that
format
we
use
all
over
the
place
and
as
a
part
of
this
PR
I
was
trying
to
understand
why
we
used
it
in
the
first
place,
but
also
how
hard
it
would
be
to
stop
using
it.
I
think
the
answer
is
that
it
would
be
probably
pretty
difficult
to
stop
using
it,
but
I
think
we
should
start
moving
away
from
it
all
over
the
place.
B
B
That's
not
something
I'm
going
to
do
in
this
PR,
but
I
think
that
that's
going
to
be
something
that
we
should
eventually
do
and
start
discouraging
the
use
of
that
HR
time
format.
If
we
can.
B
Okay,
well,
everybody
please
review
that
that
PR
I
will
update
it
I
think
with
the
fetch
fix,
so
that
those
are
done
in
the
same
PR,
so
that
we
don't
break
the
fetch
instrumentation
on
our
release.
B
These
other
two
PRS
are
just
ones
that
I
pulled
out.
That
I
think
are
relatively
mature
and
just
need
reviews.
So
when
you
have
time,
please
review
those.
B
Quick
update
on
the
contrib
release,
automation
that
there
is
no
update,
I
haven't
really
had
a
lot
of
time
to
work
on
it
in
the
last
week,
as
we've
been
dealing
with
other
other
things,
but
I
do
hope
to
have
that
probably
PR
open
this
week,
yeah
I
think
everybody's
aware
of
the
problems
we've
been
having
with
the
contrib
releases,
probably
not
much
to
say
there
Nev
do
you
have
an
update
on
the
sandbox.
D
Really
just
what
I've
got
there?
My
now
that
I'm
back
I
finally
caught
up
my
internal
stuff
yesterday,
so
for
the
next
week
and
a
bit
before
I'm
off
again
I
I
plan
to
if
I
can
create
this
merge
script,
which
will
effectively
bring
us
back
to
my
original
PR,
which
was
the
initial
creation,
so
that
main
is
effectively
a
representation
of
everything
coming
out
of
JS
and
concrete
built
using
Rush
and
roll
up
to
create
bundles
testing
with
web
and
worker.
That's
the
plan!
C
B
All
right,
logs,
API
I,
assume
Martin.
You
must
have
added
this
yeah.
E
Yeah,
it
is
mine,
so
that's
the
pr
that
you
have
been
part
of
as
well
and
I
have
looked
at
it
and
commented
just
with
some
giving
them
some
background
of
why
we
decided
we
actually.
So
when
I
originally
worked
on
the
logs
API
I
proposed
something
similar,
and
then
we
had
a
discussion
about
it
and
decided
to
do
the
simpler
way.
E
E
You
know
like
to
have
like
an
API
method
to
create
a
log
record.
You
get
an
instance,
you
get
instance
of
a
log
record
and
then
you
can
manipulate
it
and
then,
when
you're
done,
you
just
call
admit
admit
method
on
that
instance
itself.
E
So
we
decided
we
decided
to
have.
You
know
just
a
single
amid
method
on
the
logger
and
pass
in
like
an
object.
Little
like
an
actual
like
a
plane,
object
that
conforms
to
the
interface
like
log
record
interface,
I,
guess
my
question
was:
do
you
have
any
thoughts
on
this
Daniel
like
do?
Do
you
think
we
should
keep
it
this
that
way
or
should
we
consider
changing
that.
B
Yeah,
so
I
do
have
some
thoughts
on
this.
My
my
initial
thought,
when
this
PR
was
opened,
was
actually
to
reject
the
pr
I.
Definitely
prefer
the
simpler
API
of
just
having
a
single
admit,
and
one
reason
is
that
the
the
core
focus
of
the
API
is
not
for
applications
to
do.
B
Logging,
in
which
case
having
a
log
record
Builder,
might
be
a
useful
thing,
but
it's
actually
to
bridge
between
existing
log
Frameworks
and
the
exporter,
if
I
understand
correctly
so
should
be
only
receiving
fully
built
log
records
anyway
from
various
logging
Frameworks
unless
I'm
misunderstanding
or
the
scope
of
the
API
is
somehow
changed
since
the
last
time,
I
was
looking
into
it
that
I
I
don't
see
any
strong
argument
to
to
make
it
so
that
you
can
modify
log
records
before
emitting
them
and
am
I
understanding
that
correctly.
E
Yeah
yeah
I,
I
kind
of
had
the
same
thought:
I,
don't
I,
don't
really
see
an
advantage
of
having
an
instance
of
a
logger
log
record
that
you
modify
over
time.
Yeah.
B
If
it
was
meant
to
be
an
end
user
logger,
then
maybe
I
could
understand
the
use
case,
but
even
at
that,
since
it's
just
a
a
basic
key
value
pair
object,
it
would
be
fairly
easy
to
just
make
your
own
JS
object.
Add
a
bunch
of
keys
to
it
and
then
emit
that
I,
don't
see
any
value
in
having
a
specific
API
for
it.
E
E
Okay,
so
there
is
there's
that
use
case,
but
there
is
also
for
events
for
the
events
part
of
the
API
it
would.
It
would
be
used
by
instrumentations.
B
Got
it
okay,
I
mean
even
at
that
I
still
think
I,
don't
see
a
strong
argument
for
having
this
sort
of
Builder
pattern.
I
think
that
makes
more
sense
in
you
know,
compiled
and
more
strongly
typed
languages
where
you
can't
just
arbitrarily
modify
objects,
but
in
JS
we
don't
really
have
that
constraint.
E
B
E
B
E
I
I
had
I
have
a
related
question
and
then
just
from
that's
just
from
my
from
my
careers
curiosity,
so
we
when
this
this
API
the
way
it's
defined.
Currently
it's
the
logger
has
a
mid
method
and,
and
the
IT
accepts
just
a
just
a
plain
object,
but
there
is
an
interface
or
that
object
defined
in
the
API,
which
has,
which
is
basically
defines
the
fields
from
the
data
from
the
data
data
model.
E
So
the
API
has
an
interface
with
a
data
model,
and
that's
not
we
don't
do
that
for
for
spans
or
metrics
and
I
just
want
to
make
sure
that
it's
already
like
merged,
but
I
just
want
to
make
sure
that
it's
not
that
it's
that's
that
inconsistency
with
is
okay.
E
Yeah
yeah
that
so
so,
the
the
log
record
here
is
an
interface
right
and
then
by
the
interface
with
Fields,
not
with
methods
in
the
fields
correspond
to
the
data
model.
B
Yeah
I
I
understand
what
you
mean:
I
think
the
start
span
method
in
the
API.
A
E
C
E
B
What
this
even
looks
like
yeah
right
there
in
the
Tracer
file
here
start
span,
name,
options,
context,
so
I
guess
the
span
options
is
fairly
similar
to
the
data
model
in
the
logger
like
fairly
similar
to
what
you're
doing
in
the
logger
right.
B
You
can
provide
most
of
the
things
from
the
data
model
as
options.
It's
not
that
different.
It's
just
that
the
name
is
its
own
argument,
because
it's
the
only
required
one
I
think.
E
B
Personally,
I
would
rather
have
more
of
the
apis
work
like
what
you
did
in
the
logger
API,
because,
as
you
add
arguments,
some
of
these
API
methods
have
become
quite
long
and
if
they
were
objects
with
optional
key
values.
That
would
have
made
the
the
API
a
little
bit
easier
to
extend.
E
Okay,
it
makes
sense,
yeah
I
mean
so
this,
for
this
PR
I
think
sounds
good
about
just
pushing
back
on
that.
I
did
look
at
their.
They
have
another
PR.
That
was
I,
think
it's
closed
right
now.
It
seems
like
they
implemented,
not
just
the
API,
but
also
the
SDK
and
exporter,
so
they're
a
little
bit
further
ahead
than
what
I've
been
working
on.
E
E
And
this
has
like
everything
it's
good
yeah.
B
Yeah
I
think
that
that
they
implemented
like
a
full
working
SDK
at
their
company,
and
this
is
most
just
upstreaming
what
they
already
had.
So
it's
not
surprising
that
they
had
a
lot
more
complete
I
mean
I
I,
suppose
that
might
be
a
good
starting
place
for
for
exporters
and
stuff
I.
Looked
at
the
SDK
PR
that
you
had
earlier
today
and
it
looked
like
you
had
not
updated
it
this
week.
Right
no.
A
C
E
Wondering
if
I
should
continue
on
that
or
if
I
should
help
this
other
person
merge
the
SDK
that
they
have
I
mean.
So
they
have
it's
not
that
far
from
what
I
have
so.
B
B
B
Whether
you
think,
if
they're
further
along
than
you,
are-
and
you
don't
want
to
duplicate
that
work,
then,
and
it's
easier
than
great,
if
they
did
anything
if
they
did
things
in
a
drastically
different
way,
it
might
be
more
difficult.
You
know
that
their
SDK
I
assume
probably
depends
on
the
changes
that
they're
trying
to
make
in
the
API.
But
it's.
E
B
Yeah
yeah,
so
it's
up
to
you,
whichever
you
think,
would
be
less
work
for
yourself.
C
B
B
B
B
B
Double
oh
I
read
this
one
earlier,
so
metrics
are
being
initialized
twice.
It
looks
like
in
the
HTTP
instrumentation
I,
don't
know
if
This
only
affects
the
Prometheus
exporter,
I
think
it
may
be
actually
an
HTTP
instrumentation
bug,
not
an
exporter
bug,
but
he
had
noticed
that
each
metric
was
being
exported
twice.
E
C
B
Okay
from
BTS
exporter
should
use.
Oh
just
incorrect,
capitalization
I
wonder
how
that
even
happened.
B
Oh
okay:
well,
that's
an
easy
bug
to
fix
P2
incorrect
instrumentation.
B
That's
right,
I.
Remember
we
looked
at
this
last
week.
B
Maybe
the
problem
is
in
order
to
concept
I'm
already
assigned
to
this,
so
I
will
make
sure
to
look
into
this.
Okay.
A
B
This
one's
already
assigned-
and
this
one
is
known,
wait
hold
up.
I
will
actually
prioritize
this
one
though.
B
I'm
not
sure
I
haven't
seen
Rono
in
the
last
week
or
so
I
haven't
talked
to
him.
I
will
reach
out
to
him
to
see
if,
if
he
has
time
to
look
into
this,
if
not
I'll
look
into
it.
A
B
All
right,
anyone
have
anything
that
they
want
to
bring
up
before.
We
close
the
call.
F
I
was
just
going
to
mention
this
is
Jamie
I,
don't
know
if
we
want
to
move
that
redis
issue
to
the
contribbow
or
if
we
want
to
wait
for
them
to
give
more
detail.
First,
I,
don't
I,
don't
know
the
issue
in
it.
I'm
just
seeing
it
looks
like
they're
having
trouble
with
like
the
auto
instrumentations
meta
package,
which.
B
Is
on
your
trip
anyway,
I
agree:
I
think
we
could
just
transfer
it.
B
Keep
the
same
levels
I
think
thank
you,
I
think!
That's
it
done
thanks
everybody
for
your
time,
I'll
talk
to
you
again
next
week.