►
From YouTube: 2023-02-27 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
C
A
D
D
D
A
All
right
everyone
now
we
skipped
last
week,
hopefully
for
those
in
the
U.S
or
Canada.
If
you
had
a
vacation,
it
was
good,
but
we're
back
now
so
we'll
go
through
the
regular
sick
check-in
and
then
we'll
go
on
to
special
topics.
Firstly,
for
the
spec
looks
like
we've
got
some
work,
that's
been
completed
for
HTTP
semantics.
A
That
is
notable
for
maintainers.
Thanks
for
posting,
this
Armin
Armin.
Are
these
changes
pretty
sweeping
like?
Do
you
want
to
talk
to
them
more.
E
Not
it's
pretty
much
all
I
have
to
to
say
about
it.
I
think
the
one
that
gives
guidance
on
what
semantic
conventions
in
first.
It
might
be
interesting
for
maintenance,
because
they
also
have
some
context
of
what
their
users
usually
want
to
want
to
see
and
rely
on.
So
that
might
be
interesting
for
them.
A
Okay,
we'll
keep
going
no
updates
for
PHP
for
Java
for
JavaScript
we've
been
new
maintainer
Mark
pichler
welcome
Mark
new
approver
Martin
Kuba
welcome
Martin.
We
have
the
logging
API
that
was
just
merged.
The
logging
SDK
is
still
in
development.
Major
Plumbing
for
exponential
histograms
was
merged
and
they're
working
on
finalizing
that
wow
lots
of
progress
in
JavaScript
thanks
for
python,
released
1.16.0
for
go,
we're
praying
for
the
metrics
API
release
candidates,
as
well
as
the
metrics
SDK
beta
wow.
A
Another
big
milestone,
that's
excellent
and
also
preparing
to
release
to
fix
the
spec
schema
validation
tool.
Interesting,
maybe
I'm
out
of
the
loop.
Does
someone
from
go
want
to
speak
to
what
this
is
and
what
it
does?
Yeah.
C
Sorry,
there's
like
this:
the
schema
tool
itself
actually
uses
this
like
go
package
to
validate
things.
C
And
so
it
was,
it
was
it's
blocking
a
PR
from
Trask,
but
I
don't
know
if
it's
on
the
call,
but
it's
kind
of
want
to
like
call
it
out
as
like,
if
you're
trying
to
do
something
with
resource
attributes
or
all
renames
or
something
like
that
like
it
needs
to
yeah
we're
working
on
that.
A
Okay,
very
cool
I
didn't
actually
know
we
had
that
tool,
but
that
sounds
super
useful.
Thank
you
for
fixing
it.
C
To
be
clear,
Tigard
fixed
it
I,
didn't
thanks.
Thank.
A
People
for
fixing,
but
yes
perfect,
for
C
plus
plus
releasing
1.8.2
this
week.
This
will
include
the
logs
API
and
SDK
implementation,
as
per
the
newest
specs
and
significant
performance
Improvement
for
metrics
for
metrics,
there's
also
ongoing
work
for
enabling
exemplars,
no
new
updates
for
erlang
or
any
of
the
other
groups.
A
So
I
didn't
add
this
yet,
but
after
going
through,
these
I
feel,
like
one
topic.
That's
worth
discussing
is
the
logs
implementation,
like
certainly
with
traces
and
with
metrics.
At
some
point,
we
reached
a
place
where
we
felt
we
wanted
to
sort
of
start
a
process
together
across
languages
to
track
the
initial
initial
releases,
then
betas
then
release
candidates
and
finally,
the
the
ga
I
think
logs
for
a
lot
of
people
who
aren't
actually
working
on.
A
It
have
been
slightly
out
of
mind
for
a
while,
just
because
it
was
such
a
focus
on
traces,
metrics
who've
been
last
year.
Do
people
feel
like
we're
approaching
that
point
for
logs,
where
in
the
next
few
months
or
so,
we're
going
to
start
like
actually
approaching
a
an
actual
release
across
languages.
A
This
is
correct:
yeah,
that's
also
sort
of
why
masculine
like
I,
see
a
lot
of
progress
here,
but
I
know
that
the
the
log
spec
was
fairly
recently
finalized
and
I
believe
there's
other
details
and
I
could
be
wrong
about
this.
That
still
aren't
final.
Perhaps
but
I
don't
know
if
those
are
necessary
for
initial
release.
Anybody.
F
G
Can
I
can
provide
an
update
so
where
to
start
so
events,
as
as
Tristan
mentions,
have
been
a
part
of
the
the
log
discussion
the
plan
has
been
to
use.
G
You
know
to
structure
events
as
logs
on
The,
Wire
and
but
the
the
event
effort
is
really
decoupled
from
logs
we've
been
trying
to
make
that
that
clear
and
we've
been
trying
to
to
structure
the
documents
and
the
specification
to
reflect
that
we're
really
at
a
place
where
we
want
to
Mark
the
log,
API
and
SDK
documents
is
stable
and
travisca
has
provided
a
link
where
you
know
that
to
an
issue
in
the
specification
where,
where
tigern,
this
is
one
of
the
remaining
steps
before
we
Mark
those
documents
as
stable,
is
we
want
to
present
the
work
that
we've
done
in
the
log
API
and
SDK
specification
to
the
broader
community
and
collect
additional
feedback
and
yeah,
so
that's
kind
of
where
we're
at
we
got
to
collect
additional
feedback
before
we
Mark
these
documents
as
stable
and
marking
the
documents
as
stable
would
is
a
prerequisite
to
any
language
doing
a
stable
release.
A
That
makes
sense
to
me
so
so
we're
still
waiting
on
one
or
two
parts
of
the
spec,
which
is
fine,
that's
actually,
where
I
thought
I
thought
we
were
I,
guess
in
advance
of
that
I'm
actually
really
excited
seeing
all
the
progress
we've
made
across
the
language
sigs,
which
means
that
once
those
are
stable,
it
might
actually
be
a
relatively
short
process
to
to
get
the
first
beta
set.
B
D
D
So
even
we,
even
though
we
have
a
API
plus
SDK,
this
won't
be
usable
just
because
there
is
no
contending
API
to
use
it.
So
probably
you
can
see
we
may
have
to
do
some
more
work
to
have
another
layer
of
contending
API,
which
probably
we
plan
to
do
it,
but
yeah
we
do
it
so
I
mean
in
all.
We
do.
We
will
Implement
API
plus
SDK,
but
that
one
will
be
something
usable
directly
by
the
customers
as
such.
F
G
It's
called
The
Log,
Bridge
API
now
so
a
long
time
ago
there
is
a
there
is
a
decision
made
to
not
create
a
yet
another
log.
Api
many
languages.
Have
you
know
a
lot
of
Legacy
in
the
log
signal
space?
G
We
don't
want
to
reinvent
the
wheel,
creating
a
log
API
by
creating
a
log
API
and
having
to
deal
with
all
the
complexity
associated
with
that
when
you
create
an
API
you're
expected
to
provide
a
rich
set
of
you
know
configuration
tools
to
configure
you
know
what
happens
with
those
logs
with
you
know:
rolling
file,
appenders
and
you
know,
exporters
to
network
locations
and
there's
all
sorts
of
complexities,
and
so
we
didn't
want
to
do
that,
and
so
this
this.
G
What
we
want
to
stabilize
for
now
is
this
idea
of
a
log
Bridge,
API
and
corresponding
SDK,
the
idea
being
that
you
write
log,
appenders
or
Bridges
using
this
log
Bridge
API
AI,
which
Bridge
logs
from
existing
log,
Frameworks
and
libraries
into
open
Telemetry.
And
then
we
have
a
pretty
simple
SDK
implementation,
which
kind
of
mirrors
tracing
that
allows
you
to
do
simple,
processing
and
exporting.
G
So
the
idea
that
we
should
just
have
a
log
Bridge
API,
you
know
for
bridging
logs
into
open,
Telemetry
and
and
not
create
a
user-facing
log.
Api
has
been
it's
been
debated,
but
has
been
kind
of
reaffirmed
in
a
number
of
issues,
and
so
yeah
I'm,
not
sure
where
that
will
end
up.
I
I
know
that
many
Frameworks
will
will
never
create
a
a
user-facing
log.
Api.
A
Got
it?
That's
actually
super
helpful
clarification,
I'm
guessing,
there's,
probably
a
contrast
here
for
like
languages
like
Java,
where
there's
log4j
and
various
other
logging
Frameworks
that
people
use
jacket
just
to
sort
of
Channel.
What
you're
saying
I
I
think
what
you're
saying
is
in
those
ones,
there's
probably
not
much
value
in
US
offering
a
nice
sort
of
user-facing
logging,
API
SDK
experience,
because
we
should
just
Bridge
with
those
and
then
for
others
like
C
plus
plus,
perhaps
where
I
take
it.
There
is
no
sort
of
standard
go
to
logs
framework.
A
Those
ones
we
consider
offering
something
that
that's
like
a
nice
user-facing
logging,
API
SDK.
G
Yeah
and
I
think
you
know
this.
This
still
needs
to
be
discussed,
but
if
C
plus
plus
does
need
to
create
a
user-facing
log,
API
one
suggestion
that's
been
made
is
you
know,
does
does
that
need
need
to
be
part
of
the
specification?
Can
that
just
be?
You
know
a
separate
project
that
those
those
maintainers
contribute,
but
that
that
isn't
necessarily
something
that
is
specified
and
you
know
which.
C
So
I
I
would
probably
say:
if
we're
going
to
do
that,
we
should
probably
mention
that
in
the
spec
specifically
saying
that,
like
the
Spec's
not
going
to
specify
this,
because
it's
a
really
big
fear
of
maintainers,
to
try
to
do
something
outside
of
the
specification
and
say
like
well,
what
happens
when
the
spec
comes
along
and
we're
getting
free
to
find
this,
like
am
I
going
to
be
compatible
so
like?
C
G
C
G
Think
I
couldn't
dig
up
an
issue
where
that
kind
of
reflects
the
current
discussion
on
this
point,
but
yeah
and
maybe
I'll,
link
to
the
specific
part
in
the
spec,
where
we
say
that
we're
we're
not
having
a
user-facing
log
API
explicitly.
Okay,.
A
And
and
just
a
question-
and
this
is
asked
of
ignorance-
not
an
opinion,
but
but
is
this
like
a
point
in
time
thing
where
we're
saying
for
this
sort
of
first
release?
We
want
this
to
stick
or
we're
saying
long
term
for
for
languages
like
Java,
where
there's
plenty
of
good
logging
apis
we're
not
going
to
really
ever
plan
to
reinvent
the
wheel.
I
assume
it's
the
second
option
there,
but
I
just
wanted
to
clarify.
G
Well,
I
assume
it's
the
second
option
too,
but
you
know
it's
kind
of
hard
to
predict
of.
A
A
no
I
think
that'd
be
a
strange
thing:
yeah
yeah,
okay,
okay
cool!
This
has
been
super
super
useful,
any
other
questions
from
people
about
logging
or
other
other
topics.
We
want
to
discuss.
F
Yeah
I
just
added
the
configuration
file
format,
spec
update
to
the
status
with
the
Otep
that
was
opened
a
few
days
ago.
No,
it's
simple!
It's
the
last
one.
F
F
F
Can
speak
to
others
might
speak
more
to
it,
Tyler
or
that
Otep
proposes
Jason
schema,
and
so
that
was
chosen
by
the
working
group
as
the
schema
definition,
language.
C
Yeah
I
can't
I
I
mean
there's
a
there's,
an
idea
to
try
to
propose
a
way
to
define
a
configuration,
there's
a
there's,
a
kind
of
an
example
of
what
we
might
eventually
Define
in
that
configuration.
But
this
is
to
have
that
discussion
move
into
the
specification
at
this
point.
So
it's
a
pretty
high
level
overview
of
how
we're
going
to
talk
about
configuration
in
the
specification
which
would
then
you
know,
if
accepted
start,
creating
pull
requests
and
specification
for
a
configuration
file,
type.
G
It
hasn't
been
discussed
in
the
in
the
specification.
Yet
this
this
Otep
is
hot
off
the
press.
I
think
it
was
opened,
Friday,
maybe
Thursday.
So
it's
it's
quite
new
I
know,
there's
been
a
lot
of
interest
in
this,
so
you
know
please
go
read
this
and
it's
not
too
long
of
a
document
and
I
think
it'll
I
think
it'll
be
interesting
and
when
we
do
eventually
talk
about
it
in
the
spec
you
know.