►
From YouTube: 2022-06-28 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
Okay,
let's
start
thank
you
so
much
for
joining
first
academic
agenda
is
expo.
Histogram
follow-up,
gym
idea,
rounds.
A
B
B
B
B
However,
if
you're
a
user
of
these,
you
don't
care
about
how
the
formulas
are
written
and
the
amount
of
complexity
that
an
implementer
will
have
to
deal
with
is
pretty
small
compared
with
the
amount
of
angst
prometheus
came
at
us
with,
so
I'm
at
peace.
With
this
I
am
proposing
that
we
make
a
non-breaking
change
that
makes
our
formulas
more
complicated
to
make
them
happy.
I
don't
believe
that
there
is
much
upside
to
this
other
than
making
prometheus
happy
and
I'm
willing
to
do
it.
B
For
that
reason
alone,
if
you
read
through
the
pr
you'll
see,
the
pros
and
cons
are
enumerated
a
little
bit.
The
question
really
comes
down
to
exactness
otel's
histogram.
We
did,
we
didn't,
propose
anything
exactness,
anything
exact
there,
because
it's
more
overhead,
it
wasn't
part
of
the
design
criteria
and
so
on,
and
yet
prometheus
has
a
valid
case
for
some
number
of
queries
that
exist
today.
That
will
not
be
answerable
in
theory
tomorrow,
with
this
new
structure,
so
there
you
have
it.
I
recommend
that
we
do
this.
B
So
if
you
have
approval
powers
or
know
anything
about
the
exponential
histogram
in
depth,
please
take
a
look
at
my
pr
and
consider
either
rejecting
it
strongly
with
a
lot
of
rationale,
because
I
tried
my
best
to
convince
prometheus
that
this
was
a
bad
idea
and
I'm
still
proposing
that
we
do
this
to
make
them
happy.
B
I
will
open
the
floor
for
anyone
who'd
like
to
speak
in
general
terms
about
what
I
just
said
and
then
we'll
see
where
we
go
from
there.
I
actually
do
want
to
see
us
implementing
exponential
histograms
in
the
other
languages.
I
want
python,
I
want.net
I
want
javascript
tomorrow
c,
plus
plus.
I
want
all
of
them
at
this
point,
and
I
wanted
to
just
basically
report
back
jack
asked
me
four
weeks
ago.
I
think
five
weeks
ago.
Can
we
make
this
stable?
Are
we
done?
B
A
C
Metrics
so
js
maintainer
here
I
assume
that
most
of
the
other
sigs
are
in
the
same
boat
that
we
were
just
waiting
for
questions
to
be
resolved.
I'm
happy
to
do
the
js
prototype,
assuming
that
this
will
be
merged.
B
Yeah,
so
for
the
record,
my
the
actual
data
structure
of
a
histogram,
practically
speaking,
doesn't
change.
When
you
do
this
change,
it's
and
and-
and
you
can
argue
that-
there's
almost
no
impact
on
the
user,
because
you
know
at
the
end
of
the
day
you're
going
to
make
a
graph
which
you
know
you
want
to
choose
the
p90
or
p95
and-
and
the
answer
is
the
same
number.
It's
just
the
inference
that
you
get
to
make
from
that
number.
B
If
I
have
a
p95
plot
and
I
use
the
lower
inclusive
definition,
then
my
p95
value
tells
me
a
lower
inclusive
meaning.
If
I
have
an
upper
inclusive
p95,
it
tells
me
an
upper
inclusive
meaning,
and
all
that
tells
me
is
that
if
there's
an
exact
match
at
my
exact
p95,
I
know
something
stronger
in
the
inclusive
direction
than
the
other
direction.
The
the
practical
import
of
this,
I
believe,
is
almost
zero,
but
I
don't
want
to
have
an
argument
and
I
don't
want
to
be
blamed
for
you
know
a
debate
between
prometheus.
A
Thank
you
so
much
for
that
yeah.
I
think
it
makes
sense
to
actually
review
that
and
have
a
strong
opinion
on
these,
like
a
clear,
explicit
opinion.
So
we
can
make
progress
so
please,
if
you're,
a
matrix
user
you're
interested
in
this,
please
yes
like
explicit
explicitly.
No,
the.
B
Biggest
takeaway
here
is
this
change,
doesn't
matter
very
much,
it
would
benefit
all
of
us
to
have
exponential
histograms
finished
and
you
know,
let's
get
it
done
thanks.
A
Sweet
thanks
so
much
okay,
moving
on
then
otlp
partial
success.
Pr
any
concerns
can
we
merge
it
before
you
explain
jaw
more
of
these.
We
have
three
approvals,
so
that's
fantastic
because
of
how
what
it
affects
the
rc
touches.
I
would
like
to
have
more
more
eyes
on
this,
especially
from
maintainers
or
people
who
have
actually
grits
and
otp
exporters.
Otherwise,
it's
looking
good
and
I
think
we
need
more
just
a
last
review
from
bogdan.
If
I
remember
correctly,.
D
It
adds
new
feuds
in
the
in
the
proto
response
that
we
have
today,
where
it's
possible
to
indicate
the
number
of
accepted
data
points,
log
records
or
spans
and
also
another
field
to
indicate
an
error
message,
or
some
some
some
guidance
for
users
to
know
how
to
fix
the
issues
and
during
the
pr
there
was
a
lot
of
discussions
in
which
makes
sense
in
in
adding
more
structure
to
be
able
to
do
things
like
retries
and
more
more,
more
complex
handling,
also
like
some
sort
of
self-monitoring,
metrics
of
of
senders,
for
example.
D
So
for
that,
I
created
a
separate
issue
to
discuss
this
extra
extra
structure
and
to
to
not
block,
because
there
was
a
lot
that
was
also
interesting
in
move
forward.
What
what
we
have
as
a
first
version
and
then
adding
things
later
on.
So
that's
the
state
of
it
as
carlos
said,
there's
three
approvals
and
I
think
only
bogdan
had
a
comment
and-
and
I
didn't
hear
back
from
him
so
yes.
A
So,
let's
try
to
get
more
approvals
reviews
this
week
and
based
on
the
fact
that
there's
already
enough
approvals,
I
suggest-
but
you
know
this
week-
we
merge
it
unless
somebody
raises
a
concern
so
well.
Jack
is
a
maintainer
in
java,
maybe
python
golang,
javascript,
etc.
If
you
can
take
a
look
at
this
one,
this
change
just
it
would
be
fantastic.
You
know,
so
it
doesn't
surprise
you
later
yeah.
Otherwise,
let's
try
to
merge
it
by
next
week.
A
Perfect
next
one
I
put
the
item
there.
This
is
about
replacing
metrics
with
direction
label
like
metrics
that
have
a
direction
label
will
replace
them
and
we
will
split
them
into
two
into
two
metrics
instead
is
alex
around
by
the
way
I
think
alex
is
not
around,
but
bertrand,
maybe
you're
around.
Would
you
want
to
talk
about
that?.
E
Yeah
well
yeah
I
was
I
have.
I
had
some
concerns
about
the
this
change
that,
as
it
has
some
implications
on
the
current
receivers
that
would
need
to
be
updated
to
split
their
io
matrix
in.
Are
you
read
io,
send
you
write
your
received,
etc,
and
I
truly
didn't
see
the
actual
benefit.
To
be
honest,
the
first
time
I
read
the
general
semantic
conventions.
E
I
was
surprised
by
this.
The
way
it
was
done,
like
io
direction
was
well
that's
weird,
that's
something
how
it's
done
usually
and
then
I
realized
that
it
made
a
lot
of
sense
and
I
I
was
like
okay
this.
This
is
actually
a
great
way
of
you
know
doing
that,
because
you
could,
you
can't
do
math
aggregation
the
directions,
all
the
different
types
of
ios
that
you
could
have
like.
You
know,
compressed
cached,
etc.
That
may
add
up
to
the
usual
directions.
E
I
was
like:
okay,
that's
great,
and
I'm
surprised
that
now
we're
just
going
backward
to
the
traditional
way,
which
seems
to
be
more
limited,
but
I'm
probably
missing
something.
So
I
just
wanted
to
know
what
were
the
arguments
in
favor
of
bringing
this
change,
which
may
break
a
lot
of
receivers
that
we
need
to
be
updated.
A
Yeah,
probably
my
d
has
some
conflicts
on
that,
but
one
of
the
things
is
that
this
is
something
that
prometheus
indeed
recommends
to
have
them
separated,
and
there
is
one
of
the
reasons
is
that
why
doesn't
you
want
to
see
the
wreath
or
the
out
portion?
You
don't
want
to
see
both
of
them,
so
it
makes
sense
to
just
keep
them
separate,
and
and
that's
it
you
know.
So
that's
one
of
the
reasons
like
quite
often
this
is
the
use
case
you
want
one
or
the
other,
not
both
of
them.
A
At
the
same
time,
that
was
one
of
the
reasons
jamaica
may
know
more
more
details.
I.
B
Don't
know
this
is
like
an
opinion
matter,
it's
really
a
question
of.
What's
better
and
what's
worse-
and
I
you
know
this-
the
generic
convention
to
have
this.
This
label
was
from
the
earliest
days,
maybe
part
of
the
open
census
proposals.
I
I
couldn't
tell
you
where
it
came
from
exactly,
but
I
can
tell
you
after
you
know,
two
years
of
talking
to
people
about
those
conventions
and
looking
at
migration
from
past
systems.
It's
like
creating
so
much
trouble.
So
even
if
it's
a
good
idea,
it's
creating
too
much
trouble.
That's
where
I
stand.
E
Okay,
so
basically
we're
talking
about
ease
of
integration
with
other
with
the
backend
systems
that
you
know
traditionally
use
different
things.
All
collectors
that
you
know
do
that
with
separate
metrics.
B
Or
we
just
don't
want
to
have
to
go
change
the
production
of
metrics
on
all
the
clients
that
have
been
filing
these
metrics
for
10
years
and
tell
them.
We
have
a
better
way
of
doing
things
to
make
trouble
for
you.
You
know
it's
not
better
if
it
creates
that
much
trouble
is
my
opinion,
and
maybe
you
know
years
from
now,
when
there's
a
far
more
sophisticated
environment
around
these
metrics.
E
Okay,
so,
okay,
I
understand
I
totally
understand,
and
I
see
I
get
your
point
so
just
for
the
record.
We
in
my
company
we've
been
so
we've
been
working
with
the
hardware
matrix
which
I
added
to
the
agenda
just
a
few
seconds
ago.
Hardware
metrics,
and
so
we
adapted
the
io
thing,
so
it
would
reflect
what
we
have
in
the
system,
metrics
and
and
then
so
that's
how
it
was
like.
Oh,
it
actually
works
great
when
you
know,
building
dashboards
in
graphena
or
in
datadog
was
like
it
was
great.
E
E
A
And
the
changes
themselves
by
the
way
on
the
processor
shouldn't
be
like
a
major
problem,
hopefully
and
yeah,
so
just
just
for
for
just
for
reference
on
that
minor
detail.
F
One
other
comment
is
that
some
of
the
other
semantic
conventions
already,
you
know
separate
the
directions
for
things
so
rpcs
have
client
and
server
versions
of
their
of
their
metrics.
Http
has
a
request
and
response
version
of
their
metrics,
and
so
I
guess,
there's
just
more
symmetry
across
the
board
by
splitting
out
the
direction
of
things
like
network.
I
o
as
well.
E
A
Okay,
hope
that
makes
sense
yeah.
Okay.
So
if
that's
settled,
then,
let's,
let's
move
to
the
next
one.
I
also
added
this
one
grpc
status
code
added
to
semantic
conventions.
This
is
a
pr
added
by
jack.
This
is
just
the
old
grpc
status
codes
we
used
to
have
in
the
back
in
the
day
for
spans.
Now
we
just
want
to
add
them
back
into
symmetric
conventions.
A
A
Likewise,
there's
another
pr
from
jack
about
requests
and
response
sizes
for
http
requests
similar
case,
it's
pretty
straightforward,
it
basically
uses
histogram
has
been
there.
It
has
enough
approvals
now
or
I
think
no
actually,
I
think
he's
missing
one
or
something
like
that,
but
it
needs
eyes
and
I
think
it
shouldn't
be
polemical.
F
Yeah
one
comment
about
the
http
request
and
response
size,
one
so
there's
already
metrics
semantic
conventions
for
grpc
requests
and
response
size,
and
so
this
just
kind
of
brings
http
requests
and
responses
in
line
with
that.
So
hopefully
it's
not
controversial.
F
A
Okay,
if
that's
settled,
then,
let's
also
move
to
the
common
spec
consist
inconsistency
with
proto-definition
attributes
pr
by
net,
who
had
presented
that
a
pair
of
weeks
ago.
No
sorry,
yeah.
H
So
so
this
is
just
the
pr
to
address
the
issues
identified
in
the
the
issue
that
I
raised,
also
taking
into
account
the
the
link
324
issue.
Really,
what
I've
tried
to
do
here
is
just
document
the
current
state,
rather
than
define
anything
new.
I
I
A
C
H
C
I
A
That's
correct:
okay,
let's
continue
discussing
the
offline
with
the
technical
details.
The
next
item
is
from
a
bertrand
as
well
at
hardware
metrics
semantic
conventions
which
was
blocked
by
another
pr.
E
E
I
can't
remember
who
came
to
the
conclusion
that
state
set
with
this
the
way
to
go,
but
it
had
to
be
specified
somewhere
and
I'm
not
sure
where
and
how
by
who
and
whether,
then
we
could,
you
know,
move
forward
with
this
pr,
because
there's
there
has
been
a
lot
of
discussion
on
this
request
very
interesting
and
which
needs
to
be
updated
again
by
the
way
for
the
I
o
metrics,
I
mean
to
to
reflect
what
has
been
decided
for
the
system
I
use,
and
so
the
question
is
about
you
know
a
metric
representing
a
status
like
okay
or
degraded
or
failed,
should
it
be
represented
as
a
state
set
with
a
state
attribute,
okay,
degraded
and
failed
with
the
value,
zero
or
1
for
each
of
these
values,
attributes
values
or
should
it
be
an
enumeration
enumeration?
E
And
I
think
that
the
the
the
world
is
using
state
sets
and
but
it
still
had
to
be
specified
somewhere.
So
I
don't
know
how
we
could
we
can
move
forward
with
this.
B
I'm
probably
one
of
the
people
involved
in
this
conversation-
that's
been
moving
pretty
slowly.
I
I
I
feel,
like
we've
reached
a
place
where
nobody
really
wants
enough
values,
because
they
raise
so
many
complications
and
questions,
and
then
therefore
we
are
now
looking
at
this
idea
of
a
state
set
which,
as
I
briefly
would
summarize
as
a
zero
one
valued
set
of
variables.
B
That
always
adds
up
to
one,
and
I
think
that
there
was
an
efficiency
concern
which
says
that
well,
what
I
really
want
is
to
make
sure
that
I
have
to
output
one
one
and
then
all
the
zeros
are
implied,
that's
sort
of,
like
the
benefit
of
the
state
set
metric
data
structure.
B
I
feel
like
this
issue
is
interesting
and
important.
It's
slightly
less
important
to
me
than
the
synchronous
gauge
problem
that
we've
been
having
a
lot
of
people
complain
about.
So
it's
not
the
one.
I
would
work
on
first,
but
I
do
think
that
there's
a
I
would
propose
myself
a
solution
where
we
have.
We
have
this
flags
field
on
the
data
points.
B
Well,
we
also
don't
have
a
way
to
say
flags
or
properties
of
the
metric
itself,
but
this
seems
like
a
property
that
is
a
refinement
of
an
existing
type
of
metric.
So
we
have
this
up
down
counter,
which
makes
sense
for
a
zero
one
count
variable.
It
is
a
count,
so
you
know
it's.
The
number
of
states
is
equal
to
one.
B
If
we
had
a
new
bit
in
our
metric
data
model,
that
said,
I'm
a
state
set,
I
always
add
up
to
one.
Then
we
could
implicitly
output
the
one
and
forget
the
zeros,
so
it
would
be
the
proposal
that
I'm
thinking
of
which
I
don't
have
time
to
do.
The
work
on
right
now
would
be
to
add
a
bit
to
say
the
sum
of
this
metric
for
a
resource
is
one
and
x.
B
This
is
this
is
like
work,
I'm
not
sure
exactly
what
it's
going
to
say,
but
that's
how
I
would
think
about
it
and
as
long
as
when
one
gets
to
studying
the
sort
of
like
intricacies
of
the
data
model,
there's
another
flag
that
kind
of
stands
out
at
you
right
there,
which
would
be.
I
want
to
know
that
this
variable
is
always
between
0
and
1,
because
it
represents
a
utilization
or
percentage
or
something
like
that.
B
So
those
are
two
ways
to
extend
our
data
model
to
say
that
something
is
zero,
one
valued
or
always
sums
to
one,
which
is
a
really
appropriate
type
definition
for
like
probability,
distributions
and
states
that
are
always
you
know
unique
and
so
on.
But
I
just
don't
think
this
is
the
highest
priority
for
open
telemetry,
metrics.
J
B
Wasn't
prepared
to
answer
it's
a
good
question.
J
Yeah,
so
I
I
feel
this
is
the
bigger
topic.
For
example,
if
you
have
a
boeing
airplane
and
you
have
like
four
engines,
maybe
you're
saying
if,
if
two
engines
are
still
working,
then
it
is
fine,
so
I
I
think,
having
all
the
boolean
values
aggregate
to
either
one
or
zero
bits
down,
whether
all
of
them
are
one
might
be
oversimplified
but
anyways.
Regarding
this
pr,
I
I
I
feel
we
need
a
way
to
unblock
it.
I
mean
like
how
do
we
handle
vm?
J
J
J
Would
that
make
sense?
For
example,
I
think
they're
like
like
ethernet
like
adapter,
like
the
unknown
ics,
maybe
we
we
can
start
to
model
the
like.
The
outgoing
and
incoming
bits
shouldn't
block
the
pr
entirely.
F
Yeah
and
to
kind
of
extend
on
that
thought,
so,
if
we're
all
kind
of
coalescing
around
this
idea
of
state
sets
instead
of
a
numes,
you
know
we,
we
can't
perfectly
model
state
sets
today.
There's
excess
data
being
sent
that
we'd
prefer
not
to
send,
but
is
that
really
a
blocking
issue?
Can
we
can
we
model
these
as
state
sets
and
include
the
zeros
for
now
and
later
optimize,
the
the
data
model
or
the
aggregations?
In
a
way
that
you
know
we
can
omit
the
zeros
in
the
future.
J
F
J
J
B
We
should
ask
bertrand
how
he
feels
about
jack's
proposal
that
we
treat
these
as
separate
problems.
You
know
the
data
model
can
can
be
expensive
for
now
and
we
can
fix
it
later.
I
think
that's,
okay
with
me.
B
A
Okay-
the
last
item
I
put
it
there
is
just
for
your
information.
There
is
a
pr
to
clarify
the
current
compatibility
guarantees
in
otlp.
Please
take
a
look
at
that.
We
want
to
try
to
move
faster
towards
otlp
1.0,
so
yeah,
please
review
that
nothing
important
other
than
providing
a
review
there.