►
From YouTube: 2022-07-26 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
A
All
right,
I
think
that
Carlos,
our
usual
host
is
not
here,
he's
on
vacation
still
so
sure.
Could
you
kick
it
off
with
your
topic
on
otlp,
partial
success
and
anyone
else.
Please
add
yourself
to
the
attendee
list
and
any
remaining
items
to
the
agenda.
B
Right
yeah,
so
I
I
added
it
on
the
list
again.
So
this
is
the
same
thing
as
was
discussed
last
week.
There
is
this
two
PRS
for
allowing
partial
success
in
the
specification
in
the
Proto
last
week
we
had
some
ongoing
discussions
about
changing
the
semantics
from
what
we
had
of
accounting,
accepted
things
to
Counting,
rejected
things.
So
I
did
these.
These
two
changes
I
opted
to
open
new
PRS
instead
of
just
repurposing
the
existing
ones.
B
So
at
least
we
have
a
way
of
comparing
comparing
things
yeah,
so
the
changes
are
pretty
much
the
same
as
as
they
already
had
before,
just
changing
the
the
protot
to
be
rejected
and
adapting
the
text
everywhere.
B
Not
sure
if,
if
the
others
need
some
more
more
context
on
this
I
I'm
happy
to
elaborate,
but.
B
B
It's
not,
then
I
guess
just
take
a
look
yeah
and
if
you
agree
then
leave
your
approvals
there.
So
we
can
moving
forward.
A
A
That
doesn't
seem
like
it
all
right.
Thank
you
sure.
Then.
Let's
move
on
to
Luke
Mia
hi,
so
we've
got
remove
alternative
HTTP
attribute
PR
ready.
A
We
have
enough
approvals,
Christian
didn't
approve
it.
Neither
did
he
block
it.
So
I
wonder
if
he
can.
If
we
can
move
on
and
margin
foreign.
A
Should
be
sufficient,
do
you
feel,
like
you,
had
the
the
eyes
of
anyone
who
you'd
like
to
take
a
look
at
it
already
yeah
I,
think
I
did
it's
been
out
for
quite
a
while
and
I
believe
everyone
had
a
chance
to
look
and
also
had
trust,
Cut
Pro
that
yeah
all
right,
then
I'll
I'll
update
the
branch
and
merge
it
afterwards,
thanks
for
for
bringing
it
up
again,
thank
you.
C
C
Since
we're
here,
I
I
missed
the
beginning
of
the
maintainer's
call
yesterday
and
I'd
like
to
see
if
we
have
any
feeling
in
this
room
about
how
close
we
are
to
the
metrics
specifications
being
called
GA
I,
don't
know
what
is
blocking
us
at
a
spec
level.
If
anything,
I
think
we're
basically
waiting
for
more
implementation,
work
to
be
done
and
I
wanted
to
check
in
with
this
group
and
see
what
we
think.
C
D
I
see
so
so,
depending
on
whether
we
want
we
want
to
go
without
exemplary
or
not
because
exemplary
is
experimental
and
so
far
based
on
the
implementation,
I
I,
don't
think
we
have
enough
implementation
prototypes
in
the
language
six.
So
apart
from
example,
everything
else
I
I
think
it's
good
enough.
C
And
if
we
excluded
exemplars
as
being
I,
believe
acceptable
to
leave
in
experimental,
and
we
started
counting
implementations
that
have,
you
know
basically
finished
the
spec
Matrix,
my
guess
is:
we'd
have
three
ish,
but
I'm,
not
positive
of
that.
I
know
that
we're
still
waiting
for
go
and
I'm
I'm
following
that
work
and
I've
seen.net
I've,
seen
Java
I've
seen
python
seem
solid.
D
Yeah
so
besides
example,
the
premises
exporter,
spec,
is
still
experimental
and
and
I
I
think
the
blocking
issue
is
the
the
conversion.
For
example,
open
Telemetry
allows
like
metric
names
to
have
doubt
and
underscore
or
premises
doesn't
allow
both
of
them.
It
only
allows
one.
So
we
we
need
to
either
remove
certain
character
or
Escape
certain
character,
and
the
current
data
model
spec
has
a
has
a
an
experimental
section
explaining
how
that
should
be
done,
but
my
gut
feeling
is
that
might
change.
D
It
will
expose
severe
performance
concern
for
the
exporter,
because,
if
you
escape,
you
want
to
avoid
confusion.
So
either
you
develop
a
perfect
Escape
rule
or
it
can
be
imperfect,
but
you
have
to
remember
what
you
have
handled
so
far
so
in
case
there's
a
future
metric
name
that
might
cause
Collision.
You
can
reject
it.
Essentially
that
requires
you
to
remember
every
metric
name
that
you
have
seen.
D
C
I
didn't
think
we'd
ever
Mark
that
as
stable
we
were,
we
haven't
not
completed
testing.
As
far
as
I
was
aware,
although
I've
done
some
testing
with
the
job
implementation
and
my
own
I,
don't
believe
that
was
done
and
I
was
asking
the
question
originally
from
the
perspective
that
we
don't
need,
we
don't
need
exempt
bars
and
we
don't
need
high-res
histogram.
C
But
the
previous
question
is
important
and
you
know
I'm
interested
in
what
other
people
think,
but
the
other
option
is
to
ask
Prometheus
to
start
accepting,
dots
and-
and
that
is
one
I'm,
certainly
considering
myself
yeah.
C
Yeah
I
mean
I
think
that
the
things
that
are
pending
are
optional
features
that
not
every
vendor
wants
that
we're
kind
of
holding
back
on
calling
a
substantial
amount
of
work
done
because
we
haven't
finished
the
6kml
stuff.
Yet
not
very
many
people
want
so
the
the
the
time
it's
going
to
take
to
finish
those
sort
of
tail
features,
I
think
is
going
to
be
pretty
long
and
I'm
not
sure
it's
that
valuable
to
most
users.
E
So
I,
maybe
I,
don't
know
the
what's
been
released.
Maybe
that's,
maybe
that's
my
ignorance
here,
but
I
thought
that
there's
a
large
swath
of
the
definitely
the
API
and
the
SDK
specifications
that
are
marked
as
stable
and
I
think
that's.
E
C
Think
the
question
is
really
about
calling
calling
the
the
sdks
that
have
implemented
those
specs
ready
in
some
sense,
I
call
it
1.0,
but
so.
E
C
E
C
Yeah
and
I
think
I
mean
behind
in
the
background
I'm
thinking
to
myself
what
are
their
unanswers
by
questions
that
we've
left
unspecified
and
are
there
any
of
those
that
really
need
to
be
specified
like,
for
example,
there's
a
discussion
yesterday
about
what
to
do
when
you
have
extreme
High
cardinality,
and
that
seems
to
lead
to
Corner
cases
that
we
haven't
specified
and
I'm.
B
C
E
E
Well,
I,
I,
agree
and,
and
that's
why
I
was
just
kind
of
yeah,
because
that
doesn't
seem
like
it's
something
necessary
for
1.1
or
1.0,
because
it
can
be
unified,
I
think
after
the
fact,
but
yeah
I
don't
know
I
guess
you
said:
there's
three
languages
that
have
already
done
some
sort
of
stable
release.
Are
they?
E
C
Be
true
as
well
I
think
the
question
came
from
some
co-workers
of
mine.
Who
said:
are
we
ready
to
say
hotel?
Yes,
100
to
our
users
and
the
question
is
well
no,
but
which
some
libraries,
yes
and
then
kind
of
get
our
story
straight?
I'll
I'll
keep
following
up
on
this
I.
Think
we've
had
enough.
I've
got
enough
information
from
this
room
to
to
for
the
question
I
asked.
F
Yeah
I
can
say
for
sure
that
JavaScript
is
is
holding
1.0
for
a
couple
of
reasons
that
are
definitely
spec.
Related
I
would
have
assumed.
Prometheus
would
be
required
for
1.0,
it's
enr
Milestone,
that's
holding
our
1.0
release.
Another
issue
that
is
holding
our
1.0
release
is
1297
in
the
spec.
F
C
I,
didn't
I
didn't
realize
that
this
requirements
for
safe
label
removal
was
still
being
seen
as
our
as
either
as
an
option
or
a
requirement.
I
mean
it
felt,
like
part
of
the
data
model
to
me
and
I'm
curious
to
discuss
that
more,
but
I
think
the
more
important
topic
here
is
this
Prometheus
exporter
compatibility
question:
I,
don't
wanna
cut
off
that
conversation,
but
I'd
like
to
ask
David
Ash
Paul
this
question
since
he's
had
the
most
to
say
about
Prometheus.
C
You
I
think
you
had
the
issue
last
assigned
to
yourself
about
well
I
guess
this
is
actually
a
different
issue.
We
something
about
units
was
taken
care
of
perhaps,
and
is
there
any
spec
work
left
or
export
or
work
left
that
we
need
to
settle
about
how
to
handle
incompatible?
Names
is
basically
the
question.
A
The
the
one
thing
that's
remaining
that
I'm,
so
there's
a
lot
of
implementation
to
do
from
my
recollection
of
the
existing
spec,
but
in
terms
of
spec
work.
The
one
piece
that
we
haven't
tackled
yet
is
the
namespacing,
so
Prometheus
does
prefixing,
but
open
telemetry
doesn't,
and
so
that's
what
we're
talking
about.
Yeah
yeah,
the
scope,
that's
where.
C
C
All
right,
well,
there's
work
to
do.
Thank
you,
I
think
at
least
some
of
us
here
are
listening
and
we
will
come
back
with
more
clear
plans
about
this.
Thank
you
all.
E
So
I
would
also
ask
I,
don't
see
the
Java
Sig
present
here,
but
there
are
also
another
language,
that's
quite
far
along
in
their
development
of
the
metrics
signal.
I
would
love
to
know
what's
blocking
them
from
GA
or
if
they
already
consider
themselves
to
be
stable.
A
B
A
Considered
their
Matrix
sdks
GA
I
think
their
Market
is
such
in
their
release.
Notes.
E
A
F
C
C
This
leads
me
to
think
that
we're
having
sort
of
different
like
completion
bars
for
different
languages,
you
know
I
mean
I,
consider
Prometheus
important,
but
these
questions
are
really
hard
to
answer
and
for
many
users
just
want
otlp,
I
think
and
the
The
Collector
has
stabilized
the
Prometheus
exporter.
So
somehow
there's
a
stable
path
right
now
it
seems
to
be
at
least
and
enough
enough.
People
are
saying
it's
stable,
that
we
should
at
least
figure
this
out.
D
C
I
didn't
realize
that
I
thought
that,
like
a
month
ago,
Jack
was
in
this
meeting
asking
the
same
question:
are
we
ready
to
stabilize
the
exponential
histogram
and
my
answer
was
I,
don't
think
we've
seen
two
implementations
yet
I
have
an
end-to-end
test
of
one
implementation.
Where
I've
you
know
verified
that
the
numbers
are
correct,
like
in
a
light
step
dashboard,
and
then
we
did
the
same
with
the
Java
implementation.
C
That's
all
I
got
that
to
me
was
fairly
satisfying
to
complete
two
implementations,
but
we
do
also
have
this
debate
over
boundary.
Inclusivity
I'm,
not
calling
that
breaking
change,
but
it's
also
like
clearly
not
a
stable
change,
not
clearly
not
stable
for
making
that
kind
of
change.
D
So
do
you
think
it
makes
sense
for
us
to
treat
it
as
a
bug
and
add
the
experimental
tag
on
the
histogram
section.
F
So
I'm,
looking
at
the
spec
right
now
and
it
looks
like
the
problem-
is
that
the
exponential
histogram
work
was
being
done
under
a
section
that
was
all
like
marked
stable
four
months
ago
yeah.
So
it
was
the
people
working
on
it
were
considering
it
experimental,
but
it
never
had
that
tag
in
the
markdown
file.
D
F
Yeah,
so
we
also
have
a
question
sort
of
related
sort
of
unrelated
the
the
light
step
implementation.
Do
we
consider
outside
implementations
to
be
you
know,
do
we
consume
them
as
a
part
of
this
I.
C
It's
not
necessary
to
do
this
because
you
know
another
implementation
could
be
used
or
I
was
I
was
trying
to
get
an
implementation
checked
in
that
I
could
use
from
the
collector
for
the
stats
key
receiver,
because
I'm
pretty
confident
in
supplementation,
but
I
think
we
were
holding
back
on
calling
Sable,
because
there
there
were
that
many
implementations
available
I,
consider
marking
the
rest
of
the
stuff
sort
of
1.0
more
important
and
the
question
about
namespacing
and
Prometheus
is
probably
the
biggest
one
we
should
be
talking
about.
F
A
C
This
is
the
the
non-breaking,
but
it's
not
quite
stable
change,
I'm
talking
about
where
we
change
boundary
inclusivity.
The
same
thing
we
did
before
it's
just
a
more
complicated
change
here.
It
does
not
change
the
protocol.
It
changes
the
comments
in
the
protocol
yeah.
C
C
However,
this
topic
of
the
the
name,
the
namespacing,
is
like
likely
to
be
a
mess,
I.
Think
and
it's
because
although
the
Prometheus
open
metric
specifications
do
talk
about
what
is
a
namespace
and
using
underscores
to
prefix
the
namespace
to
the
metric
name,
that
is
a
sort
of
concept,
not
a
mechanics,
a
mechanical
feature
of
their
API,
so
generally
speaking,
users
type
in
the
name,
including
that
namespace,
so
users,
don't
always
think
of
the
namespace.
C
And
when
a
user
comes
to
open,
Telemetry
and
they've
been
used
to
Prometheus
they're,
probably
just
going
to
type
in
the
same
name,
so
they'll
type
in
HTTP
requests,
which
is
the
namespace
prefixed
to
the
metric
name.
Requests
I'm
I'm,
not
sure
what
I
mean.
I
I
actually
think
that
we've
discussed
how
instrumentation
scope
is
for
declaring
your
library
name,
but
that
you
probably
would
not
use
that
instrumentation
scope
as
a
namespace,
because
the
idea
of
instrumentation
of
instrumentation
library
was
that
you
could
swap
them.
C
So
I
want
to
be
able
to
swap
a
library
without
changing,
namespaces
and
I.
Don't
think
the
users
want
automatic
namespacing
from
from
an
Hotel
Library,
the
name
that
they
type
in
should
be
the
name
that
they
get
if
they
put
namespacing
as
an
open
metric
style
of
prefix
on
their
metric
name
in
Open,
tracing
I
think
open
Telemetry.
We
should
just
pass
that
through
to
Prometheus
and
when
it
comes
back,
it
should
come
back
with
a
namespace
prefixed.
C
C
F
F
C
A
F
F
Yeah
and
then
you
do
run
into
the
problem
that
Josh
was
just
talking
about
where
then,
when
you
go
to
change
your
Library,
your
namespace
changes,
maybe
an
optional
namespace
configuration
is
better.
C
Yeah
I'm
not
convinced
we
need
namespaces;
basically,
it
seems
orthogonal
and
it's
not
like
we're
saying
you
can't
put
namespaces
in
it's
a
name.
Sources
are
not
the
same
as
instrumentation
scope,.
F
A
F
C
Right,
like
they're
the
same
metric
name
but
they're
different
because
they
belong
to
different
instrumentation
scope,
so
they
they.
You
know
you
have
a
sort
of
user
interaction
problem
because
they
want
to
display
with
the
same
name,
but
they
came
from
different
places
and
we
haven't
really
solved
this
problem.
They
might
stop.
We
don't
treat
the
instrumentation
Library
name
as
like
a
distinguishing
and
if
you
have
collisions
you
have
collisions
and
that's
like.
Actually,
we
haven't
had
a
lot
of
problems
with
that.
C
And
I
actually
thought
that
the
original
purpose
of
instrumentation
Library,
you
know
like
it's
debatable
but
like
one
of
the
requests
with
that
feature,
was
to
be
able
to
turn
off
an
entire
library
of
code.
But
I.
Remember
that
when
we
discussed
the
idea
of
swapping
in
a
new
or
replacement
library
of
code
should
come
in
with
the
same
metric
names
different
and
you
know
so
that
they're
the
same
metrics.
There
are
different
different
instrumentation
libraries
so
that
two
two
HTTP
instrumentation
libraries
they
should
produce
the
same
metric
names.
C
The
the
pre,
the
namespace
in
that
case
is
HTTP,
underscore
they're
already
using
it,
but
the
users
type
that
in
and
I
remember
we
asked
some
of
the
Prometheus
developers
like
namespace
is
like
do
what
you
will
with
it.
That's
that's
like
that's
like
concept,
not
not
mechanics
in
in
Prometheus,
I.
Think.
A
A
Doesn't
have
the
same
concept
of
conventions
that
we
do
so
it's
unlikely
that
two
HTTP
metrics
would
actually
have
the
same
dimensions
and
stuff
if
their
names
were
the
same,
which
is
why
namespaces
namespacing
is
important.
If
all
the
open,
Telemetry,
instrumentation
libraries
look
exactly
the
same,
then
maybe
you
could
merge
them.
C
Right,
we
could
just
have
an
option
that
says
you
know
now
that
we
have
scope
attributes,
you
could
have
a
scope
attribute
schematically
defined
as
a
prefix
namespace,
and
then
you
set
the
scope
attribute
on
the
scope
that
says
my
name.
Space
is
something
something
and
then
all
the
metrics
in
that
that
meter
will
have
the
namespace
prefixed
to
avoid
confidence.
C
Prometheus
they
end
up
with
those
prefixes
when
they
come
back.
You
know
to
us:
I
mean
I
what
I
guess
I'm
expecting
that
is
that
the
metrics
produced
in
that
namespace
in
that
scope,
just
have
the
namespace
included
and
they're,
not
they're,
not
like
you,
don't
have
to
keep
attaching
it
like
implicitly,
every
time
you
look
at
this
object
like
when
you
create
a
metric,
you
put
that
short
name
in
front
of
it
done
you're
not
is
what
I'm
trying
to
say.
B
I
I
was
going
to
say:
wouldn't
we
be
able
to
use
the
beta
name
and
and
the
other
attributes
as
dimensions,
and
then
some
somewhat
be
able
to
differentiate
between
the
library
swapping
case
that
you
mentioned,
because
there
will
be
both
HTTP
requests.
But
then
you
can
use
the
you
can
split
by
the
by
different
libraries
or
by
different
components
to
see
the
HTTP
request
for
only
those.
C
Yes,
I
understand
your
meaning.
There
I
think
that
that
would
practically
not
work
in
some
systems
and-
and
that's
probably
where
this
concern
comes
from,
like
you
know,
there
may
be
metric
systems
where,
because
of
the
stuff,
we
talked
about
safe,
attribute
removal,
like
you
know,
two
libraries
producing
different
dimensionality
but
they're
both
called
HTTP
requests
and
you
can
remove
some
attributes
from
one
and
get
to
the
other
and
they're
the
same
at
that
point.
C
So
maybe
it's
okay,
but
in
a
system
where
you,
where
you
honor
the
instrumentation
Library,
what
Schwab
just
said
is
true:
you
can
treat
them
as
independent
and
you
know,
sort
them
and
slice
them
and
display
them
at
the
same
time,
because
they're
they're
just
time
series
coming
from
different
places
with
the
same
name:
okay,.
B
The
other
thing
that
is
also
linked
is
this
issue
that
I
post
in
the
chat
that
there's
a
there's,
an
issue,
but
it's
about
attributes
but
I
think
it.
It
falls
into
the
same
thing
that
there's
a
precedence
of
of
attributes
when
exporting
to
Primitives,
for
example,
okay,
because
we
will
have
the
same
problem
with
Collision
on
attribute
levels
if
they're
defined
on
the
resource
or
and
then
now
on
the
scope
and
and
then
in
the
actual
data
point,
and
what
to
do
with
this
with
them.
In
that
case,
I.
F
Agree
that
it
blocks
Prometheus,
I,
guess
my
question
does
Prometheus
block
the
metrics
SDK
1.0
can
cut
the
JavaScript
SDK,
for
example,
go
to
1.0
without
Prometheus.
C
I'm
not
sure
we're
going
to
answer
this
here
either.
So,
let's
all
of
us
who
have
a
stake
here
think
about
how
to
move
this
question
forward
in
the
coming
week,
and
maybe
we
can
continue
this
discussion
in
the
Prometheus
working
group
tomorrow
morning
tomorrow
tomorrow.
Is
it
tomorrow,
I
forget
which
week
I'm
in
possibly
tomorrow,
possibly
next
Wednesday.
A
C
Thanks
for
taking
notes,
Riley,
we
need
to
make
some
progress
and
well.
Thank
you
all.
If
anyone
else
has
anything
speak
now,
please,
because.