►
From YouTube: 2022-11-07 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
D
D
C
A
B
All
right,
so
we've
got.
B
B
Semantic
convention
stability,
working
group
yeah,
it's
every
other
Monday,
not
this
Monday
is
Josh.
Anybody
here
want
to
talk
about
that
have
been
going.
This
is
really
important.
Work,
I,
think
getting
I.
Think
the
recent
in
the
last
meeting
we
were
discussing
trying
to
get
HTTP
kind
of
really
focusing
on
like
HTTP
semantic
convention
seem
to
be
pretty
much
ready
to
be
stabilized,
except
the
fact
that
then
we
realized
it's
only
for
traces
and
likely.
B
We
would
want
to
do
the
same
for
metrics
to
make
sure
there's.
You
know
nothing
that
that
would
affect
the
tracing
HTTP
semantic
conventions,
but
I,
like
the
focus
on
try,
try
just
to
get
our
very
first
semantic
convention
over
the
stability
hurdle
would
be
amazing.
D
Yeah
we're
We've
meant
to
have
our
metrics
GA
released
last
week,
but
on
Friday
Riley
Yang
completed
the
TC
review
and
brought
up
a
couple
of
issues
which
none
of
them
are
are
particularly
like
groundbreaking,
but
we
want
to
make
sure
we
at
least
address
everything
before
we
release
so
we'll
release
sometime
this
week.
I
would
expect.
D
Both
yeah,
so
we
had
a
separate
metrics
API
package,
we're
merging
it
into
the
main
API
package,
which
is
already
a
stable,
so
it'll
be
a
minor
version
bump
on
our
API,
which
includes
metrics,
and
the
SDK
packages
will
also
be
released
as
one
dot.
Eight
I
think.
B
E
Yeah
I
can
give
a
quick
update
there.
We
are
just
proceeding
along
with
developing
our
new
metrics
SDK,
we're
in
the
beta
development
phase,
now
getting
some
good
feedback,
especially
with
the
collector
starting
to
implement
use
of
that
SDK
as
well.
E
So
we're
making
progress
there
and
expect
to
have
the
the
next
Point
34
release
I
would
notice
for
probably
next.
B
E
It
was
using
open
census
before
so.
I
was
using
the
open
census,
metrics
API,
to
construct
metrics
for
items
received,
processed
and
exported
at
each
point
in
its
Pipelines.
B
All
right,
I
think
that's
the
end
of
update.
Then.
D
Yeah,
so
I
have
a
a
specific
issue
linked
here,
but
I
I'm
really
asking
more
generally.
How
do
we
handle
situations
like
this
I
think
in
this
particular
case?
It's
going
to
be
just
that.
The
specification
has
a
something
missing
because
the
so
that
the
issue
is
that
during
our
TC
review,
Riley
noticed
we
have
Force
flush
on
our
metric
reader,
which
is
not
specified
as
a
metric
reader
operation.
D
If
you
look
at
the
force
flush
on
the
specification
for
the
meter
provider,
though
you'll
see
that
it
says
specifically
that
it
should
call
Force
flush
on
all
metric
readers,
so
that
definitely
seems
to
imply
that
it
should
be
there
but
I'm
asking
more
generally.
If
there
are
apis
that
are
like
not
in
the
specification
should
it
block
the
release.
D
I
think
in
in
this
specific
ish
issue,
I
think
it
just
works
out
to
be
a
specification
clarification
needed.
But
how
have
other
cigs
handled
things
like
this
and
who
decides
whether
something
is
a
a
language
concerned?
Does
that
require
TC
approval,
or
is
it
something
the
individual
language
maintainers
get
to
decide.
B
E
Error
record
exception
when
we
were
initially
implementing
the
trace
spec,
but
that
was
ultimately
formalized
in
the
spec
spec.
One
was
record
exception.
We
stuck
with
record
error,
but
the
the
behavior
was
formalized.
D
Yeah,
it
was
eventually
formalized
and
I
think
it.
This
one
is
going
to
turn
out
to
be
a
bad
example,
because
it
is
just
a
a
fairly
obvious
spec
issue,
but
we
had
similar
I
remember
when
tracing
was
being
stabilized.
We
had
similar
issues
I'm
just
trying
to
just
trying
to
to
ask
really
who
has
the
final
say
as
to
whether
an
exception
should
be
approved
or
not.
Is
that
something
individual
language
maintainers
can
decide
or
something
that
needs
to
be
escalated
to
the
TC.
F
I
think
in
general,
if
there
is
some
inconsistency
or
something
is
unclear,
then
it
makes
sense
to
create
an
issue
in
respect
and
and
discuss
it
there,
but
I
guess
it
will
depend
on
the
individual
case.
Sometimes
we
say
that
there
should
be
no
other
apis
for
good
reasons,
and
sometimes
it
just
specifies
what
should
be
there
but
doesn't
claim
what
should
not
be
on
there
and
then
it
probably
depends
on
on
what
you're
adding
there
if
it.
F
If
it
is
something
you
you
can,
you
can
just
decide
on
your
own
or
if
it
should
be
specified
explicitly
that
that
it's
something
to
not
go
in
there,
and
sometimes
it
explicitly
points
out
that
it's
up
to
language
maintainers,
to
figure
out
what
the
what
the
respective
best
version
for
their
for
their
framework,
calling
which
is
I.
A
F
Think
we
can,
we
can
have
any
any
any
answer
that
that
generally
works
there.
E
Yeah
I'd
just
like
to
chat
a
comment
on
an
issue
in
the
go
repo
that
Riley
had
made
regarding
a
kind
of
similar
issue
where
we
were
looking
at
whether
we
could
provide
more
flexibility
for
specifying
views
than
I
think
the
the
spec
anticipates
and
his
guidance
is
basically
the
specs
of
minimum.
If
you
want
to
go
beyond
that,
you
can
just
be
careful
about
how
you
do
so,
especially
if
it's
an
area
that
the
spec
may
want
to
later.
E
Formalize
and
I
think
this
Force
flush
would
be
one
of
those
areas
where
we
should
probably
decide.
If
we
want
to
do
that
on
the
metric
reader
or
not
and
formalize
it
rather
than
leaving
it
open
and
unspecified.
D
Yeah
I
in
this
specific
I,
don't
want
to
focus
on
the
force
flush
too
much
because
it
is
actually
specified
on
meter
providers
and
that
meter
provider
spec
references,
the
force
flush
of
the
metric
readers
and
just
assumes
its
existence.
So
to
me,
it
just
seems
like
a
spec
bug,
but
that
philosophy
of
the
spec
is
a
minimum.
I
think
is
something
that
should
be
formalized
by
the
TC.
D
If
it's,
if
that's
going
to
be
something
that
we're
going
to
treat
as
a
policy
to
me,
I
see
a
big
difference
here
between
the
API
and
the
SDK
as
a
language.
Maintainer
I
am
typically
very
hesitant
to
implement
anything
in
the
API.
That's
not
specified,
although
it
has
happened
in
the
SDK
I
would
say.
Probably
every
language
implementation
has
hundreds
of
methods
that
weren't
explicitly
specified
by
the
specification.
There's
just
no
way
to
specify
everything.
D
D
D
So
it
it
seems
to
me
like
the
SDK,
should
be
treated
as
a
specification
is
a
minimum.
Well,
it
gets
other
other
functionality
is
sometimes
implemented
on
top
of
it.
There
are
language
specific
concerns,
not
any
not
everything
can
possibly
be
specified,
but
the
API
is
much
more
of
a
explicit
Target,
where
you
want
to
very
carefully
consideration
or
to
very
carefully
consider
anything
that
you
add
to
the
API,
which
is
not
specified.
B
D
I
I
just
think
this
is
something
that
TC
should
address,
probably
at
the
TC
meeting.
D
One
important
break
from
from
this
sort
of
proposed
policy
is
that
in
the
past,
both
Morgan
and
Ted,
who
are
both,
unfortunately
not
here-
have
been
supportive
of
adding
convenience
methods
to
the
API
and
things
like
that
which
are
not
explicitly
in
the
spec,
which
is
obviously
not
in
compliance
with
with
what
we
just
proposed
here.
So
I
mean
that
I
I
think
this
is
something
that
the
TC
should
come
up
with.
A
policy
on
that
can
be
applied
consistently.
F
Yeah
I
was
just
checking
if
we
have
something
like
that.
Already
in
the
in
the
library
guidelines,
talk
that'd
be
happy
to
speak,
but
I
can't
find
anything.
I'll
talk,
yeah.
We
will
look
into
that.
I'll
I'll,
bring
it
up
on
the
TC
chord,
but
I
think
the
The
General
feeling
that
we
already
seem
to
share
with
API
is,
is
rather
an
exact
stack
and
the
SDK
is
rather
a
minimum
with
some
really
roaming.
F
C
Yeah
I
was
just
hoping
at
least
to
get
sort
of
understanding
of
what
languages
are
supporting
this
untraced
idea.
Untraced
is
a
method
or
function
that
you
can
wrap
other
code
in
and
it
will
cause
it
not
to
create
spans.
C
The
this
came
up
today
again
in
the
the
from
an
erlang
user
who
wants
this
because
they
have
some
database
queries
that
go
off
the
whole
bunch.
They
don't
want
spans
created
for
it.
There's
a
lot
of
them
going
they're
cut
just
kind
of
unrelated
to
the
application
logic
or
something
I
guess,
and
so
he
was
asking
how
he
could
do
that,
and
this
is
the
best
way
I
I
can
think
of.
But
we
don't.
C
We
don't
have
an
untrace
function
yet
in
erlang,
because
there
are
limitations
to
the
way
that
like
Ruby
did
it,
which
is
it
requires
it
being
the
sampler
parent
base
being
used.
There's
no
like.
If
you
don't
use
a
parent-based
sampler,
then
it's
not
going
to
actually
be
untraced.
It
will
create
spans
potentially,
depending
on
what
sampler
you
used.
I
guess
JavaScript
has
another
solution,
but
it
didn't
seem
I,
don't
think
it's
used
by
anybody
else
either
and
certainly
nothing's
in
the
spec.
C
So
I
was
hoping
to
get
since
a
bunch
of
people
from
different
languages
are
here
some
idea
of
what
people
are
doing.
If
anything.
D
D
It's
important
for
we
initially
added
it,
because
exports
were
being
traced,
they
used
the
internal
HTTP
Library,
which
was
automatically
instrumented,
so
we
were
in
a
loop,
so
it
was
a.
It
was
a
requirement
for
us
to
build
our
exporters
and
it
was
initially
meant
to
be
used
only
internal
to
the
SDK.
D
It
has
also
been
used
in
some
instrumentations
to
suppress
the
underlying
details.
I
guess
like
if
you're
using
a
HTTP
Library,
which
uses
the
standard
Library
HTTP
under
the
hood,
you
don't
need
both
of
those
spans.
So
you
suppress
the
inner
span
and
a
couple
of
other
situations
like
that.
I
would
say
it's
not
particularly
widely
used
and
we
don't
really
advertise
it
because
we
consider
it
to
be
kind
of
an
SDK
internal.
D
But
it's
something
that
was
asked
about
has
been
asked
about
a
lot
yeah,
so
I
tried
I
tried
to
get
it
into
the
specification
like
a
year
and
a
half
ago,
and
oh
forever.
I
I
eventually
just
gave
up
because
we
needed
to
implement
our
exporters.
C
B
So,
on
the
on
the
Java
side,
we
we
don't
have
any
anything
quite
like
that,
like
like
a
completely
separate
property,
we
generally
do
the
the
sampler
right
and
the
parent-based
sampler,
if
you
want
to
suppress
like
in
general,
like
noisy
spans,
is
the
primary
use
case
for
this.
In
particular,
we
do
have
some
some
pretty
nice
actually
stuff
that
Ludmilla
had
designed
and
she
had
opened
a
spec
or
Otep
about
this
after
implementing
it
in
Java.
B
But
basically
it
gives
you
the
flexibility,
because
we
have
in
Java
a
lot
of
these
cases
where
we
have
some
like
HTTP
library,
that
uses
some
other
HTTP
library
or
has
a
plugable
HTTP
library
with
multiple
things,
and
we
can't
always
know
if
we
should
instrument
which
level
so
it
now
by
the
default
setting
and
there's
three
different
settings.
But
the
default
is
that
if
it's
of
the
same
semantic
convention,
so
an
RPC
span
will
suppress,
nested
RPC
spans
HTTP
span
will
suppress
nested
HTTP
spans,
which
still
allows
you.
B
Then,
if
you
have
a
like
a
messaging
library
that
uses
HTTP
underneath
you
get
both
of
those,
but
it
also
has
an
option
to
suppress
all
nested
client
spans,
which
is
helpful
for
some
back-ends,
which
don't
support.
Nested
client
spans
well,.
B
C
B
I
can
try.
I
can
dig
up
that
the
spec
issue
that
lidmilla
had
opened
good.
C
C
Nobody
else,
then
it's
can
offline,
go
back
through
these
oteps
and
and
pull
requests
and
see
what
we
can
see.
What
comes
out
thanks.