►
From YouTube: 2022-06-15 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
A
You
won't
have
to
hear
me
talk
about
it
anymore,
so
this
was
more
just
a
note
to
myself
here
when
I
was
making
the
agenda,
but
I
I
I
figured
I'd
put
it
in
here,
just
as
I
current
topics
of
focus
just
in
case,
anyone
is
unsure
what
they
should
be
working
on,
anything
that
helps
towards
the
metrics
ga,
which
there
is
a
milestone
for
and
anything
where
you
can
help
with
documenting
the
new
metric
api
and
sdk,
which
is
currently
under
documented,
and,
I
believe,
needs
to
be
documented
before
we
can
release
it
as
ga.
A
That's
that's
our
current
areas
of
focus
if
you're
looking
for
something
to
do,
anyone
have
any
questions
on
that
before
I
move
on.
No,
it's
a
fairly
minor,
then.
A
A
I
was
looking
into
this
a
little
bit
this
morning
and
I
found
that
there
is
some
options
that
we
can
try.
The
biggest
one
here
is
the
sequential
calls
option,
so
by
default.
It
makes
calls
in
parallel
and
the
documentation
on
this
option
explicitly
says,
may
reduce
failures
due
to
throttling.
A
So
I
think
I'm
going
to
try
to
enable
that,
but
if
anybody
is
aware
of
any
other
way
to
either
increase
the
rate
limit
or
reduce
the
impact
of
release,
please
on
the
relate
on
the
the
rate
limit.
If
anyone
has
used
it
in
the
past,
please
let
me
know
for
now
I'm
going
to
try
to
at
least
implement
that,
but
for
those
who
have
been
patiently
waiting
on
the
packages
to
be
released.
A
I
am
manually
releasing
those
packages
today
there
was
another
small
issue
that
was
causing
the
build
to
fail,
but
I
believe
we've
at
least
temporarily
resolved
it
and
we
can
actually
release
those
packages.
I
just
haven't
had
time
to
do
it
this
morning,
but
I
will
do
it
this
afternoon.
B
Sorry,
what
was
the
the
option
you
wanted
to
enable.
A
B
Yeah
after
the
last
hiccup,
the
previous
hiccup
with
the
packages,
I
actually
enabled
this.
So
if
this
release
was
recent,
which,
as
far
as
I
understand
it,
was
then
the
option
is
already
enabled.
A
Yeah,
okay,
so
I
also
did
create
an
issue
on
the
release.
Please
action,
letting
them
know
that
we're
running
into
this
problem.
I
guess
I
will
add.
A
A
We
could
also
do
separate
pull
requests
which
would
open
like
50
different
pull,
requests
there
to
merge
pr,
you
know
to
release
packages,
but
each
one
would
be
would
only
create
a
single
release.
We'd
merge
them
all
individually,
but
that
would
also
prevent
us
from
hitting
the
rate
limit.
Both
of
those
seem
like
painful
options
to
me,
but
they
are
a
possibility.
A
A
So
if
anybody
has
any
other
issues
or
ideas
or
ways
that
we
can
work
around
this,
let
me
know-
or
if
there's
another
release,
automation
tool
that
we
should
look
into
again.
I
think
that's
kind
of
painful.
I
don't
really
want
to
do
that,
because
it's
hard
enough
getting
one
set
up
and
there
may
be
unseen
unforeseen
issues
with
another
one
that
we
may
just
end
up
back
in
the
same
place.
A
But
at
this
point
I
don't
we're
kind
of
at
a
standstill
here.
I
don't
really
know
what
else
to
do
if
we've
already
enabled
that
flag
so
we'll
see
what
they
what
they
say
on
the
issue.
A
Okay,
in
terms
of
the
metrics
ga,
I
added
a
link
to
the
milestone
here.
You
guys
have
all
already
seen
this
if
you're
looking
for
something
to
do.
This
is
a
great
place
to
look
the
three
main
things
that
I've
pulled
out
of
here
are
documenting,
which
we
always
need
help
with,
but
there's
also
two
important
metrics
prs
that
are
in
need
of
review
this
first
one's
fairly
big.
A
I
started
reviewing
this
this
morning
and
I'm
still
working
on
it,
but
there's
a
lot
of
files
changed
and
it's
fairly
in-depth.
I
understand
it's
difficult
to
review
prs
like
this,
but
it
does
need
to
be
done.
The
second
one,
the
min
max,
is
not
so
big.
A
It's
a
little
bit
non-obvious
how
it
works,
but
it's
not
too
bad.
I
think
mark
is
on
the
call.
If
you
want
to
talk
about
this
pr
at
all
or.
C
So
I'm
very
aware
that
it's
kind
of
non-obvious
and
it
does
some
trickery.
I
also
took
some
inspiration
from
the
java
sdk
there
how
that
works,
but
basically
there's
a
little
bit
of
a
workaround
for
the
for
for
getting
the
delta
minute
max,
which
is
a
bit
harder
to
figure
out.
It's
basically
just
on
on
creating
the
div,
it
resets,
the
old,
the
old
histogram,
so
that
the
minion
max
doesn't
stay
from
the
old
ones
and
basically
you
have
a
fresh,
fresh
mint
and
a
fresh
max
every
time
which
yeah.
C
C
Right
so
it
would
just
continue
to
be.
Let's
say
that
the
max
maximum
is
like
10
and
there's
another
value
which
is
5
then
on
a
cumulative
histogram.
It
would
stay
to
be
10,
and
if
you
would
like
to
create
a
delta
histogram
from
that,
then
you
obviously
can't
go
back,
because
you
just
have
the
value
10
and
the
value
5
is
lost
because
it
was
smaller
than
the
previous
maximum.
And
this
is
why
it
resets
the
the
min
and
the
max.
A
Do
you
know
if
you
said
you
took
a
little
bit
of
inspiration
from
the
the
java
implementation?
You
said
right
yeah,
so
they
they
obviously
had
to
do
the
same
thing.
Do
you
know
if
they.
C
Had
to
do
the
same
thing
about
this,
no,
I
think
this
is
just
the
way
we
implemented
the
the
histogram
aggregation,
it's
very
similar
to
the
java
one.
So
they
have
to
do
the
same.
I
think
in
python.
C
A
A
So
please
review
that
anyone
have
any
questions
on
that
before
I
move
on
on
either
of
these
pr's.
D
So
the
meeting
is
a
bit
late
to
me,
so
I'm
and
I
didn't
usually
join
me
so
hopefully.
B
D
Give
you
that
to
the
pr
so
basically
vr
is
adding
a
support
for
the
reseller
detection
to
the
matrix
sdk
and
the
result
reset
detection
is
designed
for
the
async
monotonic
aggregations
and
the,
and
they
use
that
is
not
very
meaningful
to
the
non-monotonic
aggregations.
So
that's
the
whole
point
for
the
monotonic
aggregations,
like
counters,
obviously
available
counters,
primarily
for
over
the
work
of
the
countries
so
and
the
pr
is
trying
to
fix
a
issue
for
the
unexpected
negative
values
observed
by
delta
exporters.
D
As
I
listed
in
the
copy
of
the
listing
description
of
the
pr
it
primarily,
it
picks
two
primary
issues
in
that
one
is
that
if
the
exported
value
won't
won't
export,
it
will
no
longer
explode
negative
values
for
data
exporters
for
monotonic
monotonic
aggregations,
since
molecular
aggregations
are
never
going
to
be
negative
once
they
are
going
always
going
to
increase
by
time
over
the
time,
and
the
second
is
that
we,
the
specified
the
metric
streams,
are
exported
with
the
start
time
and
end
time
to
indicate
the
time
spans
of
the
exported
matrix
data.
D
If
we
mapped
the
material
map
with
views
at
a
some
aggregators,
so
this
the
instead
detections
are
primarily
fixing
the
two
second
two
significant
issues
for
the
matrix
supporting
so
and
I
I
have
listed
some
examples
in
the
description
of
the
pr.
So
people
can
review
the
pr
with
the
descriptions
with
the
timetable
in
the
descriptions
and
comparing
the
and
possibly,
we
can
play
around
with
the
pr
to
like,
say
to.
D
A
Yeah,
I
think
the
description
makes
sense.
Your
your
connection
is
breaking
up
a
little
bit.
It's
a
little
bit
hard
to
understand
you,
but
I
think
the
description
and
the
issue
sums
it
up
nicely.
A
The
important
part,
the
the
most
important
part
of
this
that
I
see
is
the
resetting
when
you,
when
you
have
a
monotonic
async
counter,
for
example,
and
you
you
export
one
and
100
than
200.
If
you
export
one
you're
violating
the
monotonicity,
which
means
that
the
counter
has
been
reset
and
that's
what
this
pr
is
handling
is
that
is
that
correct.
A
A
A
Obviously
the
metrics
sdk
is
is
useful
without
it,
but
it
is
a
part
of
the
spec
and
we
should
implement
it.
The
a
couple
of
these
are
already
like
this
one,
this
one,
this
one
are
already
underway,
so
those
will
definitely
be
done.
A
The
prometheus
exporter
again,
the
this
is
required
to
release
the
prometheus
exporter
as
1.0,
but
we
could
release
the
metrics
sdk
without
the
prometheus
exporter
being
1.0.
If
we
absolutely
needed
to.
A
The
rest
of
this-
let's
see
this
is
a
documentation
topic
which,
like
I
said,
I
believe
documentation
should
be
required
before
we're
really
ga
and
then
yeah.
So
this
is
also
documentation
topic.
So
this
is
really
a
part
of
that
I
mean
I
I
think.
Essentially,
everything
here
is
required.
A
D
Okay
and
another
one
is
that
the
crash
remote
remove
angular's
attributes
in
the
magic
instrument,
because
it's
primarily,
we
are
waiting
for
the
spec
and
it's
not
not
very
active
recently,
but
I
maybe
we
can
ask
for
the
spectrum
to
see
if
this
backward
is
it
before
the
ga,
so
that
we
can.
D
The
the
feature
is
very
useful
for
delta
exporters,
since
they
can
remove
unused
attributes
and
the
memory
will
going
up
over
the
time
and
we
can
really
remove
your
unused
attributes.
So
it's
better
to
have
and
we
can
work
without
work
without
it.
Definitely
so.
F
A
Ga,
if
we
need
to
right
yeah
right
okay,
so
that
one
also,
but
I
mean
that
yeah
the
rest
of
it
does
need
to
be
done.
Does
that
answer
your
question
svetlana.
A
Okay,
so
I
know
a
lot
of
people
are
not
as
familiar
with
the
metrics
sdk
and
maybe
looking
for
something
else
to
do.
Like
I
said,
documentation
is
always
helpful,
but
that
does
require
some
familiarity
with
the
sdk.
A
So
I
was
trying
to
think
of
other
things
that
that
don't
require
as
deep
knowledge
of
metrics
in
particular
and
the
biggest
thing
that
I
found
that
we're
lacking
right
now
is
user
experience,
it's
very
annoying
to
set
up
the
sdk
for
both
tracing
and
metrics.
A
We
have
a
few
performance
issues
that
we've
known
about
for
a
while
that
we
just
haven't
really
had
time
to
look
at
and
the
the
experience
of
writing.
Instrumentations
is
not
terrible,
but
not
ideal
either,
particularly
because
of
some
dependencies
that
the
instrumentation
module
had
on
the
metrics
sdk,
which
was
causing
every
time
the
metrics
updated
all
of
the
instrumentations
had
breaking
changes.
A
I
don't
really
think
I
need
to
talk
about
any
of
them
in
particular,
some
of
them
we've
already
talked
about
in
the
past,
like
the
async
resources
work
that
aaron
was
working
on.
I
don't
know
if
aaron
is
on
the
call
today,
but
this
may
be
another
place
to
dedicate
some
time
if
you're
looking
for
something
to
do
and
you're
not
as
familiar
or
as
comfortable
with
the
metrics
sdk.
A
Does
anybody
have
any
questions
about
any
of
these
topics,
or
you
know
interest
in
sort
of
leading
the
charge
on
one
of
these?
If
somebody
wants
to
to
take
point
on
one
of
these,
I
think
that
I
would
really
appreciate
that
as
well.
A
Yeah
I
mean
it's
to
fix
it
in
the
sandbox
is
is
great,
but
it's
something
that
also
affects
us.
So
I'd
like
to.
G
Yeah
the
whole
point
they're
doing
they're
doing
stuff
in
the
sandboxes.
If
it
works,
we
then
push
it
back
to
the
main
repo.
So
that's
yeah,
that's
the
goal
and
the
sandbox.
A
G
A
The
user
that
created
this
issue
proposes
a
like
a
different
way
to
go
about
it
that
I
I
think,
is
reasonable.
The
biggest
issue
is
that
it's
not
backwards
compatible
yeah.
It
could
be
done
in
a
backwards
compatible
way.
We
would
just
have
to
maintain
both
apis,
probably
mark
one
of
them
as
deprecated,
which
is
not
the
end
of
the
world.
In
my
opinion,.
G
A
A
A
In
this
particular
instance,
I
guess
they
are
using
web,
but
they
the
proposal
completely
removes
the
idea
of
the
global
yeah,
which
is
one
way
to
go
about
it.
It's
not,
I
think,
technically
specification
compliant,
so
we
have
to
maintain
the
global
registration
as
an
option,
but
it's
an
interesting
concept
and
I
think
a
lot
of
people
would
think
that
this
is
a
more
obvious
way
to
set
it
up,
so
it
might
be
worth
looking
into
yeah.
G
G
A
I
know
aaron's
already
working
on
the
next.
One
doesn't
look
like
he's
on
the
call
today,
but
I
know
he's
still
working
on
this
when
he
has
time.
A
I
think
this
next
issue
is
the
thorniest
one.
There
are
a
lot
of
packages
that
we
have
to
install
to
get
a
sdk
working.
I,
the
the
basic
sdk
itself,
only
has
a
couple,
but
once
you
start
adding
instrumentations,
it
really
gets
out
of
hand
pretty
quick
and
certain
instrumentations
only
support
various.
A
You
know
certain
versions
of
the
sdk
as
things
are
stabilized,
this
should
be
less
of
a
problem,
because
the
instrumentations
will
be
able
to
work
with
more
versions
of
the
of
the
api
and
the
sdk
as
they
stabilize
the
the
biggest
problem
with
the
versioning
compatibility
is
metrics,
so
once
that's
stable.
That
would
really
alleviate
that
problem
a
lot,
but
this
is
something
that
I
haven't
really
thought
too
much
about
how
we
can
solve
this.
But
if
somebody
wants
to
give
it
a
crack,
I
would
really
appreciate
it.
A
I
think
everything
else
is
fairly
fairly
obvious
here.
There's
some
performance
issues,
they're
they're
fairly
self-explanatory
on
the
issues.
A
G
Probably
the
auto
shutdown
one
I'll
be
looking
at
that
in
the
sandbox
as
well,
because
yeah
just
listening
to
unload
is
problematic,
but
I'm
not
gonna.
Look
at
it
next
week,
we're
probably
talking
months
before
I
get
to
that
part
of
it.
A
Yeah,
okay,
as
far
as
I
know,
I
I
don't
really
know
how
other
ways
that
we
can
that
we
can
look
into
this.
So
this
this
is
caused
not
by
anything
that
our
unload
handler
does.
But
it's
just
purely
by
virtue
of
having
an
unload
handler.
G
Yeah,
so
the
the
way
you
do
it
there's
a
factory
four
events
that
you
can
listen
to.
It's
unload
before
unload
visibility,
change
and
page
hide
they're,
not
all
supported
by
every
browser.
The
way
I've
done
this
in
app
insights
is
effectively,
we
listen
to
all
four
by
default,
but
we
give
you
the
ability
to
exclude
unload
and
before
unload
so
effectively.
If
you
say
I
want
to
exclude
before
unload
it
will
try
and
capture
whatever
events
it's
got
left
if
it
fails
to
capture
any
events.
G
G
A
Thank
you
for
that.
I
will
summarize
that
on
the
issue
once
we
finish
the
meeting
here.
A
A
Okay,
so
this
next
one
something
we've
talked
about
a
handful
of
times
in
the
past-
dropping
support
for
old
node
runtimes
mark
brought
this
up
to
me
earlier
this
morning
as
a
question,
does
it
make
sense
to
do
this
now
before
we
release
metrics?
That
way,
we're
not
releasing
metrics
with
support
for
old
versions
and
then
immediately
removing
it?
A
I
think
this
is
something
that
we've
been
sort
of
kicking
the
can
down
the
road
and
not
really
doing.
We've
agreed
that
it
makes
sense
to
do,
but
we've
never
really
decided
that
like
now
is
the
time
or
now's
a
good
time,
and
I
think
there
probably
never
really
will
be
a
good
time.
A
So,
if
nobody
has
any
objection,
I
think
I'd
like
to
start
working
on
removing
support
for
node,
8
and
10,
or
removing
at
least
the
the
testing
for
those
runtimes,
at
least
from
the
experimental
packages
as
a
start,
and
then
we
can
see
how
it
goes
from
there,
I
suppose
for
for
now.
This
is
just
a
I'm
just
letting
you
know,
that's
something
that
I'm
going
to
do
and
now's
the
time
to
speak
up.
If
you
think
that's
a
mistake,.
F
Yeah,
it's
just
just
clearly
quickly,
just
a
request
for
folks
to
review
this
otep.
It
started
as
a
proposal
to
add
events
api.
Now
it's
actually
combined.
There
was
a
discussion
in
the
logs
sick
last
week
and
decision
was
made
to
combine
the
events
api
with
the
logs
api.
F
So
there
will
be
a
single
api
for
both,
so
this
will
affect,
I
think,
the
work,
the
upcoming
work
for
blogging,
and
we
will
also
the
the
client
instrumentation.
We
will
start
working
on
a
prototype
for
the
events
api.
So
I
think
this
this
otap
is
probably
close
to
being
agreement,
but
I
just
wanted
to
bring
it
up
in
this
in
this
to
see,
if
for
folks,
to
have
a
look,
because
it
will
be
implemented
in
in
the
js
sdk,
probably
probably
one
of
the
first
ones.
A
Okay,
yeah
I've
looked
into
this
I've
not
specifically
added
a
review
to
it,
just
because
it's
a
little
bit
outside
of
my
area
of
focus,
but
I
will
take
another
pass
through
it
and
and
add
my
my
thoughts
and
review
on
that
on
the
pr.
A
Okay,
anybody
have
any
questions
on
that
before
we
move
on.
A
Okay,
I'm
going
to
kind
of
just
breeze
through
the
ending
here
then
I
there
are
a
handful
of
new
issues
created
since
we
had
our
last
meeting
some
of
them.
We've
already
talked
about
like
the
performance
issue.
Here
I
linked
above
in
the
user
experience
stuff.
A
A
From
my
mind,
I
I'm
a
little
bit
hesitant
to
do
this,
because
I
don't
want
to
it's
just
one
more
like
public
stable
api
that
needs
to
be
maintained,
but
if
anybody
feels
strongly
that
this
is
something
we
should
do,
I'm
open
to
arguments-
I
guess
I'm
I'm
kind
of
on
the
fence
here.
I
I
see
the
value
in
what
they're
asking,
but
I'm
a
little
bit
hesitant
to
increase
the
public
stable
api
service
surface.
That
needs
to
be
maintained
theoretically
forever.
D
I'm
I'm
not
very
strong.
I
don't
have
any
very
strong
opinion
about
it,
but
I
would
insist
that
if
we
do
that
we
should
minimize
the
service
interface
since
we
almost
all
the
methods
of
the
permit
parameters.
Civilizer
are
currently
marketed
in
public.
So
that's
the
first
steps
to
do
to
make
them
as
private
before
we
actually
do.
The
exposing
another
point
is
that
I
I
was
wondering
that
promises
supports
pushing
the
metrics
to
the
parameters
gateway
and
we
are
currently
not
supporting
investigating
the
times
on
exporting
the
push
models
for
parameters.
D
Possibly,
we
can
export
the
parameters
rather
to
other
public
api,
so
people
can
do
it
by
themselves,
since
that
could
be
very
straightforward
for
them
to
do.
A
A
It
looks
like
so
we
already
do
have
like
the
that
express
request
handler,
because
people
wanted
to
include
the
the
prometheus
endpoint
in
their
already
existing
applications
instead
of
starting
up
a
new
server.
So
it
looks
like
where
it
had
a
workaround
for
that.
I
have
not
looked
into
the
responses
to
that
workaround,
but.
D
I
think,
as
they
have
a
they
have
a
very
long
discussion
about
the
solution,
but
the
problem
with
the
solution
is
that
the
handler
is
bonded
to
the
interface
type
or
the
request
and
response
we
are
using,
which
is
not,
may
not
be
very
compatible
to
other
conditions
that,
let's
say
people
have
their
own
http
servers
and
the
their
servers
define
a
different
ships
of
requests
and
the
response,
whereas
you
realize
exploding
so
they
are,
they
may
have
hard
times
to
adopt
the
adopt
the
handlers
we
are
exposing
so
well
with
with
the
serializers
they
can
be
easily
to
serialize
the
output
and
with
their
own
http
servers,
either
with
the
different
requests
or
response
types
they
are
giving.
D
So
that's
the
one
thing
to
know
that
riot
is
not
very
not
against
the
point
and
they
are
trying
to
explain
the
point
of
exposing
the
parameters
series.
As
I
can
tell
in
the
discussion.
A
A
D
A
Yeah,
that
makes
sense
to
me
and
the
serialized
method,
I
assume,
is
a
relatively
obvious
interface
right,
yeah.
D
A
Okay,
but
it
seems
reasonable
to
me,
I
guess
you
know,
like
I
said
I
don't
feel
particularly
strongly
one
way
or
the
other.
I
just
typically
tend
to
lean
on
the
side
of
minimizing
the
the
interface
as
much
as
possible,
but
if
it's,
if
it's
solving
a
real
problem,
I
guess
we
can,
we
can
export
just
the
one
function
and
that
should
work
for
them.
A
Nev,
it
looks
like
you
added
something
here.
While
we
were
talking.
G
Yeah
just
a
couple
of
things
as
part
of
copying
over
the
code
into
the
sandbox,
I
noticed
that
well
trying
to
to
keep
the
api
compatible,
that
a
real
readable
span
is
actually
not
a
span.
It's
just
an
interface,
and
then
the
sdk
is
part
of
one
of
the
functions
once
a
readable
span,
which
means,
if
you
create
your
own
spans,
you
can't
pass
it
because
a
readable
span
is
not
a
span,
but
that's
one
of
the
things
which
once
I
get
it
all
working
and
we
get
the
original
one.
A
G
A
A
You
shouldn't
be
able
to
call
set
attributes,
for
example,
on
a
readable
span.
B
F
A
There's
only
just
problems,
the
span
should
be
missing,
essentially
what's
what's
sdk
private
or
specific
from
the
readable
spam,
because
we
don't
want.
You
know
the
the
span.
If
you
look
at
the
the
specification
of
the
span,
it's
it's
very
specific
that
a
lot
of
the
properties
are
not
public.
Obviously,
in
javascript
we
don't
really
have
control
over
that.
We
just
we
only
have
the
types
that
we
publish
and
that
are
you
know.
We
just
expect
the
users
to
respect
types.
A
You
can
always
obviously
do
whatever
you
want,
but
yeah.
That's
that's
the
core.
Like
reasoning
behind
behind
that
issue,
is
it
actually,
you
said
it's
causing
a
problem
for
you
where
you
have
to
cast
things
to
any
and
your
tests.
G
Yeah,
so
so,
once
I
I
changed
the
api,
so
it
was
actually
using
the
sorry
once
I
changed
the
sdk's
functions.
Sorry
to
use
the
api
versions
that
that's
been
causing
was
causing
some
grief,
because
the
re-double
span
only
has
properties
on
it
that
the
span
doesn't
expose
yeah.
G
Yeah,
which,
anyway
I'll,
have
a
look
at
that
again
now
that
I've
got
a
clarification
and
the
other
one
was
the
with
the
trace.
There
was
a
the
same
thing
with
trace,
so
once
I
get
the
sandbox
up
and
running
and
we
play
with
it,
then
we
can
look
at
creating
a
pr
and
pushing
the
whatever.
The
proper
fix
is
back
to
the
core.
A
A
A
Beyond
those
things,
there's
a
couple
of
new
pr's
that
are
in
need
of
reviews
and
some
old
pr's
that
have
been
waiting
around
for
reviews
for
a
while.
So
as
usual,
please
review
these.
When
you
have
time
particularly
old
prs,
I
know
as
as
a
pr
author,
it
can
be
frustrating
when
a
pr
sits
around
for
weeks
without
being
reviewed.
A
So
please
take
a
look
at
these.
As
you
have
time,
we
have
about
eight
minutes
left
if
there's
anything
else
that
somebody
that
anybody
wants
to
bring
up.