►
From YouTube: 2022-07-06 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
B
We
we
have
104
103
kind
of
consistently
in
in
austin
now
for
the
last
couple
of
weeks,
so
it's
really
hot.
D
A
All
right,
let's
start
so,
I
see
jack
added
one
item
to
the
agenda
and
he
can't
make
the
meeting
today.
So
it's
about
the
ability
to
mutate,
the
logs
in
the
processors.
We
did
discuss
this
last
time,
so
I
guess
he
he
was
planning
to
do
some
research.
So
probably
that's
what
the
issue
is
about.
I
didn't
have
a
chance
to
have
a
look
at
it,
yet
it's
yeah
it's
just.
He
has
just
posted
it.
Yeah
I'll,
probably
take
a
look
at
it
after
this
meeting.
A
Yeah,
I
guess
no
one,
it's
okay,
because
it's
new,
so
yeah!
Please
have
a
look
at
it
comment
and
we,
if
needed,
we
can
discuss
it
in
the
next
meeting
next
week.
A
A
So
we
have
enough
approvals
to
get
it
merged
already,
but
I
want
to
keep
it
open
for
a
bit
more,
particularly
because
there
were
significant
changes
to
it
since
it
was
first
created.
So
I
want
to
make
sure
that
people
still
have
a
chance
to
review
the
the
recent
modifications
to
it,
but
I
commented
on
the
authentic
mentioned
every
approver,
every
spec
approver.
So
unless
somebody
objects,
I
will
give
like
a
couple
more
days
and
I
will
merge
it.
If
I
don't
see
any
objections.
A
Hopefully
we
don't
so
we'll
be
good
to
move
with
that.
If,
once
the
otep
is
there,
we
should
be
able
to
start
submitting
prs
against
the
specification
which
of
the
actual
api,
so
the
this
other
turned
out
to
be.
I
guess
unusual
in
the
sense
that
it
doesn't
list
all
the
details,
but
I
think
it's
fine
in
the
past.
A
We
did
have
all
depths
like
this,
which
were
more
like
the
intact,
which
described
the
intent
and
the
the
purpose
of
the
autep
was
to
align
people
to
make
sure
that
no
one
objects
to
to
the
intent,
which
I
think
we
do
have
here
in
this
particular
case,
with
all
those
approvals.
But
anyway,
as
I
said,
let's
keep
it
open
for
a
bit
more
and
we
should
be
good
to
go.
D
Okay,
didn't
I.
D
You
know
the
content
that
I
removed,
where
it
would
go
in
the
specification
report
so
that
I
can
start
preparing
vr
I'll
comment
appear
only
after.
D
A
Yeah
we
have
the
we
have
api.md
and
sdk.md
for
for
traces
and
and
metrics
right.
So
let's
try
to
keep
the
the
similar
structure.
I
would
start
with
with
the
api
dot
md
and
the
current.
There
is
a
document
with
the
name
I
think
overview
right
under
the
logs.
That's
the
name
of
the
thing
give
me
one.
Second,
I
will
double
check
so
under
the
logs.
We
have
no
it's
not
overview,
it's
logging,
library
sdk.
A
So
this
probably
either
this
becomes
the
sdk
dot
md
or
we
split
it
and
the
the
the
bits
that
are
equivalent
to
what
we
have
to
the
traces
sdk
stay
here
and
the
rest
goes
into
a
separate
document
like
the
usage
stuff
with
the
diagrams,
how
to
use
it
for
the
appender
and
all
that
stuff
probably
can
be
a
separate
document
like
maybe
precisely
usage.md
or
something
like
that.
A
The
reason
is
just
to
make
it
more
more
similar
to
what
we
have
for
traces
right,
because
there
we
don't
have
that
it's
more
dry
version
of
the
specification
in
the
traces.
So
we
should
probably
it
would
be
good
to
for
consistency
to
mimic
that
that
approach
with
two
files,
api
and
sdk
and
then
anything
extra
that
we
have
for
logs,
can
be
a
separate
document.
A
I
can,
I
can
repeat
it,
so
I
was
suggesting
that
for
consistency,
we
go
with
api.md
and
sdk.md,
and
the
usage
examples
that
we
have
in
the
current
logging
library
sdk
can
be
a
separate
file.
A
D
And
then
there
will
also
be
semantic
conventions
for
the
event,
dot
name
and
right
and.
A
Again,
similarly
to
yeah,
we
can
do
it
in
a
similar
way
to
the
traces
there's
a
there's,
a
subdirectory
called
semantic
conventions
under
the
trace
directory.
D
A
Yeah,
I
would
I
would
I
wouldn't
do
it.
Experimental
is
just
stuff
that
doesn't
fit
the
regular
signals,
the
traces,
metrics
and
logs
things
like
z,
pages
and
stuff
that
is
anyways
the
stuff
that
is
outside
of
the
the
normal
focus
of
the
specification,
I
would
say
for
logs,
we
have
the
directory
the
top
level
logs
directory.
Let's
just
put
our
stuff
there.
We
clearly
mark
the
documents
as
experimental
anyway,
so
there
is
no
confusion
here.
Okay,.
A
A
C
Don't
see
yeah
yeah,
I
probably
have
a
question-
that's
probably
for
youtuber,
so
I've
got
some
comments
on
the
spec
pr
about
the
inconsistency
and
almonds
come
back
and
he
wants
to
be
clarified
so
the
in
the
spec.
It
calls
out
that
it's
just
for
logs,
which
I
didn't
put
that
there
originally,
because
I
didn't
think
that
was
the
place
we
want
to
identify
that
in
the
spec.
Maybe
a
lookup
table
identifying
that
it's
only
for
logs
today,
but
what's
your
view.
A
C
Like
to
say,
okay,
let's
start
discussing
implementing
it
for
other
signals
and
and
whatever
yeah.
D
C
The
the
inconsistency
is
really
case.
Well,
proto
supports
this.
So
therefore,
when
we
say
attributes
this
is
what
attributes
look
like,
then
we
should
say
well,
this
is
what
attributes
look
like
from
a
spec
perspective
and
like
in
the
spec,
I'm
sort
of
saying
that
it
may
contain,
and
it
should
do
this,
but
I'm
not
saying
they
must
or
have.
I
think,
that's
a
separate
discussion
so
from
the
spec.
I
think
I
just
want
to
say
this
is
how
it's
defined,
and
then
we
have
something
else.
A
A
Yeah,
I
guess
to
make
it
easier
to
move
forward
with
this,
and
I
think
I
agree
with
you
on
on
the
longer
term
the
vision
for
it
right.
But
since
it's
it's
it's
difficult.
So
maybe
just
do
the
small
thing
right.
Just
just
specify
that
maybe
maybe
say
that
the
the
otlp
allows
nested
a
nested
object
and
stuff.
But
but
the
api
does
not
for
traces
and
metrics
and
it
does
for
logs
right
so
explicitly
list
all
three
signals
and
say
what
is
supported
and
not
supported
in
the
specification.