►
From YouTube: 2022-12-13 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
Yeah
so
first
item
on
the
agenda:
is
we
released
1.4.0
rc1
packages
rc1
packages
yesterday?
B
B
Item
to
the
agenda,
so
we've
been
getting
some
internal
complaints
about
data
laws
for
histograms,
but
so
I
was
wondering
if
this
could
have
anything
to
do
with
it.
So
we
had
this
synchronization
issue
where
the
read
thread,
which
is
the
snapshot,
the
thread,
doing
collect
and
then
the
update
rate.
B
They
were
not
using
the
same
synchronization
mechanism
to
update
these
values
for
histograms,
so
like
one
was
locking.
I
think
this
was
the
update
of
the
collect
thread
which
was
locking
on
it,
and
this
was
using
its
own
interlocked
construct.
B
So
this
change,
firstly,
I
think
I
feel
one
thing
I
can
definitely
do
is
add
this
to
the
changelog
and
this
change
didn't
go
up,
go
into
any
of
the
stable
releases,
so
1.3
1.3.1
don't
have
it
and
it
only
made
it
to
the
so
only
starting
1.4
beta
one.
B
B
Because
I
think
the
only
problem
there
is
like
and
take
snapshot
in
the
collect
method.
We.
B
No
I
think
I
yeah,
that's
what
I
want
to
ask.
Firstly
like
is
it:
does
it
make
sense,
I
think
we
should
just
to
be
safe,
but
I
still
haven't
been
able
to
put
a
finger
on
like
where
the
problem
exists.
So.
A
What
is
the
the
reports
of
data
loss?
Look
like
I
mean
I'm.
Just
looking
at
this
code
refreshing
my
memory
I
mean
I.
Think
the
big
issue
is
the
the
buckets.
Are
the
thing
that's
you
know,
obviously
not
atomic
in
any
way.
B
So
the
issue
is
mostly
that
when
the,
when
the
volume
is
low
and
I
don't
know
by
volume,
do
they
mean
multiple
threads
like
a
lot
of
multiple
threads
accessing
or
like
updating
histogram
in
parallel
or
if
it's
probably,
that,
like
there
are
a
lot
of
requests.
So
every
request
is
running
on
its
own
thread,
trying
to
update
the
histogram.
But
the
issue
is
that
and
in
a
normal
volume
scenario
they
see
the
data
getting
emitted
correctly.
B
So
like
they
see
the
num
the
amount
of
data
they
expect,
they
see
it,
but
under
high
volume
scenarios
there
is
data
loss,
so
they
like
see
considerable
amount
of
histogram
values,
not
being
reported
like
the
histogram
count
recorded,
is
less
than
what
they
expected.
A
D
B
E
B
I
feel
like
there
is
something
going
wrong
with
the
metric
Point
status.
Synchronization
like.
B
E
B
So
we
won't
even
call
the
take
snapshot
method,
which
is
in
the
metric
point.
B
Oh
yeah
yeah,
like
we
use
like.
B
C
B
B
B
And
yeah
like
so
this
point
at
this
point,
I
feel
like
it
has
already
taken
a
snapshot
of
what
the
running
value
was.
Now
it's
just
assigning
earning
value
back
to
zero,
so
everything
any
updates
that
might
happen
up
until
this
point
will
could
be
lost.
I
feel
because.
B
B
Also,
the
person
who
has
this
issue
we've
asked
them
to,
like
you
know,
try
a
newer
version,
which
has
this
fix
to
see
if
that
resolves
the
issue.
So
we
can
be
sure
that
this
was
the
thing
causing
the
metric
loss
but
they're
on
functions
and
I
think
they
might
run
into
issues
with.
F
A
C
D
B
And
also
like
I
have
another
question
so
like
here.
The
metric
Point
status
is
updated
inside
the
log
right
like
even
with
the
fix.
If
we
look
at
the
code
today,
I
think
we
just
have
a
instead
of
a
lock.
This
is
now
they're,
both
following
the
interlocked
construct,
but.
B
B
A
Yeah
I
guess
what
would
be
the
consequence
just
kind
of
talking
this
out,
so
an
update
happens,
but
an
export
cycle
is
in
process
and
so.
B
B
Not
that
much
of
an
issue
that
I
think
yeah
should
be
fine,
but
another
thing
I
think
I
noticed
was
so
for
take
snapshot,
which
is
the
collect
cycle.
B
Please
change
it
to
collect
pending
if
you
feel
that
the
values
got
updated
like
if
there
was
some
update
thread
which
changed
it
during
the
time
we
were
doing
all
of
this
right,
so
we
changed
that
to
collect
pending
again
after
setting
it
to
no
click
pending
on.
This
is
only
happening
for
counters.
B
A
D
A
A
A
G
D
A
A
F
A
A
That's
what
it
is
yeah
you're
right
so
like
basically
for
Delta.
Only
when
it
hasn't
been
changed,
we
don't
export
it
based.
G
B
B
Yeah,
so
in
the
snapshots,
it's
always
under
a
lock
I
think
it
should
get
the
Fresh
Value,
not
the
stale
values,
because,
like
lock
and
interlock,
statements
would
create
all
of
those
memory,
barriers
and
stuff
right,
I
think
so
there
we
should
be
guaranteed
to
not
run
into
those
issues.
The
thing
that
might
happen,
and
since
this
is
always
a
signing,
it's
not
even
the
leading
device.
We.
D
B
This
one
I
think
there
is
like
a
major
lock
somewhere
up
there
like
a
uber
level
lock
when
collect
is
called
right,
because
we
make
sure
that
no
two
collect
threads
can
run
at
the
no
two
threads
can
run
collect
at
the
same
time
like
I'm,
going
to
go
to.
D
B
B
A
No
I
agree,
I.
Think
it's
good
to
patch
seems
like
you
know.
If
we
do
spend
more
time
studying
the
this
metric
Point
status
stuff,
you
know
that
might
be
a
thing
that
we'd
want
to
patch
in
the
future
as
well.
If
we
found
problems
but
that
you
know
that
that
could
be
a
separate
thing.
B
A
C
D
B
An
interesting
question
about
updating
change
logs,
which
I
ran
into
for
Geneva
exported
on
Contra
people.
E
B
Okay,
so
so
here
it's
simple
because
you
create
a
new
Branch
at
1.3.0
and
then
there's
nothing
on
top.
So
you
just
add
your
changes
right,
but
this
is
there's
no
mention
of
these
things.
On
our
like
current
or
your
current
branches.
Current
mean
branches
change
log
so
like
like
go
to
and
I
don't
know.
If
we
should
do
it
or
like
that's
something.
Maybe
we
should
decide
if
it's
even
needed
so.
B
So
if
we
just
put
it
chronologically,
it
will
come
up
like
somewhere
here
where
that
change
is
actually
made.
So
this
was
September
6.,
so
somewhere
between
Alpha
2
and
beta
1,
we'll
have
an
entry
for
1.3.1
if
we
just
arrange
it
chronologically,
but
the
issue
with
that
is
1.3.1
does
not
have
all
the
changes
of
Alpha
2
and
Alpha
1.
like
if
someone
is
reading
it.
That
way,
like
you
know
like
from
a
just
from
top
to
bottom
thinking
like
okay
rc1
is
guaranteed
to
have
all
the
changes
that
have
come
underneath
it.
B
But
if
we
add
1.3.1
here
right
above
1.3.0
to
sort
it
like
alphabetically,
then
Alpha,
1
and
Alpha
2
didn't
have
the
those
changes
that
were
that
went
as
part
of
1.3.1.
B
And
if
yes,
then,
how
do
we
place
it
and
like?
How
do
we
make
it
clear
that,
like
what's
the.
A
D
A
D
A
Maybe
we
just
well
okay,
let
me
continue
this
thought.
So
if
we,
if
we
kept
a
separate
branch-
and
we
just
had
effectively
like
a
a
fork
of
the
change
log
right
and
so
we
didn't
try
to
intermix
them,
then
the
question
becomes
like
how
do
people
discover
yeah
the
change
log
relevant
to
their
the
version?
They're.
B
D
A
G
A
G
A
B
So
yeah
like
it
was
decided
to
release
the
stable
version
by
John
31,
because
we
would
want
more
usage
from
people
and
we
don't
expect
much
usage
of
our
new
libraries
and
the
rc1
changes
in
December
during
vacation
time.
So
yeah
just
letting
you
all
know.
B
A
Sounds
like
now
yeah
they
they
manage
stuff.
They
manage
all
this
differently
from
the
standpoint
of
like
making
these
things
visible,.
A
I
think
you
know,
maybe
what
makes
sense
now
that
you
know
one
three,
the
one
three
line
is
kind
of
a
kind
of
a
thing
right
that
we
expect
people
may
want
to
use.
Even
once
one
four
is
released,
you
know,
maybe
we
just
make
that
more
visible,
like
in
the
on
the
top
level.
Readme
just
say
like
here's,
the
change
log
for
the
current
line,
here's
the
change
log
for
the
one
three
one.
E
A
A
A
If
you
did
like
I,
don't
know
status,
colon
I'm
just
this
is
just
a
shot.
Wait.
C
B
Okay,
I
think
we
should
like,
maybe
think
about
it
or
think
over
it
and
see
like
you,
don't
have
to
make
all
the
changes
now,
but
just
something
to
think
about.
A
And
here's
another
just
thought:
I
think
it's!
Okay!
If
we
do,
you
know
just
speaking
generally,
not
about
this
specific
patch
like,
but
when,
whenever
we
want
to
do
a
patch
I
think
it's
okay
to
do
a
patch
and
and
release
it
and
then,
as
far
as
like
change,
log
stuff,
come
back
and
you
know
fix
things
up.
A
If
we,
if
we
see
value
and
organizing
it
differently
right,
yeah
just
to
say,
I,
think
they
can
be
separate
efforts.
Yeah.
E
A
E
F
B
D
D
B
F
I'm
wondering
if
like
I
don't
know,
is
there
like
a
mechanism
to
roll
them
up
because,
like
if
you
go
to
like
the
open,
Telemetry
Dash
collector
repository
like
they
have
a
change
like
that's
in
the
root,
and
then
it's
like
really
easy
to
see
like
for
what
version
the
changes
happened.
F
They
don't
have
like
a
stable
release.
Yet,
though,
so
you
know,
I,
don't
know
how
patching
would
work
in
their
case,
but
like
they're,
changing
like
here
like
contains
that
all
the
changes.
B
Yes,
if,
whatever
packages
had
a
1.3.1
release,
all
of
their
individual
change
logs
will
be
updated.
G
B
G
Ask
you
know
we
mentioned:
we
don't
publish
the
change
log
to
nougat
if
we
just
started
doing
that,
so
that
when
you
view
a
package
version
on
nuget,
you
have
the
change
log
right
there.
Does
that
solve
our
issue?
Does
it
help
s
I'm,
trying
to
find
a
package
that
does
that
I
can't
find
one?
If
anybody
knows
of
once.
G
G
A
Nothing
super
interesting.
We
do
set
the
nougat.
G
C
A
It
goes
back
to
the
like
the
it
doesn't
link
to
the
repo
we
we
just
all
of
our
products.
Release
notes
are
published
on
our
doc
site,
so
it
just
adds
a
link
to
it's
just
basically
static.
F
A
A
D
G
G
G
The
kid
hit
the
little
view
file.
G
E
Some
part
of
the
decision,
but
let
me
send
a
link
yeah.
We
are
talking
about
the
same
thing
so
yeah,
let's
see
system
examples
from
measurements.
E
B
Yeah,
this
can
also
work
yeah
mm-hmm.
We
don't
expect
the
tax.
We
don't
expect
to
update
the
tags
to
where
they're,
pointing
so
I
think
a
hash
would
definitely
never
change,
but
if,
if
achieving
this
is
easier,
I
think
we
can
explore
that
as
well.
A
E
Like
yeah
I'll
have
to
check
this
is
something
that
we
yeah.
It
just
comes
from
the
juristically
settings.
D
D
G
A
Yeah
good
to
me,
too,
I
am
taking
some
days
off,
but
I
will
be
working
Tuesdays
the
next
couple
weeks.
So
if
things
come
up,
I
I
will
be
available.