►
From YouTube: 2023-03-29 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
B
Let's
get
started,
there's
a
short
agenda
today,
I'm
not
sure
who
added
these
items,
I
suppose
it
was
probably
tigrant
tigrants
not
able
to
attend
this
meeting
today.
B
The
first
item
is
about
the
naming
of
the
logs
Bridge
API.
B
There
was
a
comment
in
a
couple
weeks
back
when
we
presented
the
plan
to
stabilize
in
the
specification
Sig
that,
whatever
we
do,
should
shouldn't
get
in
the
way
of
a
future
and
user-facing
log.
Api.
B
You
know
just
a
refresher
that
the
log
Bridge
API
is
intended
to
be
used
by
appenders,
which
is
a
form
of
instrumentation
rather
than
by
end
users,
and
to
address
this
issue.
My
recommendation
was
that
you
know
from
a
artifact
naming
perspective.
The
the
terms
Bridge
or
Pender
didn't
appear
in
the
artifact
name.
B
B
Satisfy
that
need
so
you
know:
I
have
a
PR
open
that,
basically,
you
know
says
this
much
and
adds
some
normative
language
to
the
bridge,
API
document
that
says
that
the
terms
bridge
and
appendician,
in
effect
it
shouldn't,
appear
in
any
artifact
package
or
class
names.
B
You
know
essentially
codifying
what
I
just
said,
and
so
there's
some
discussion
happening
here.
I,
don't
know
if
any
folks
on
the
call
have
opinions.
If
you
do,
you
know,
we
should
probably
talk
about
them
on
this
issue,
where
the
other
folks
have
been
engaging.
C
Hey
Jack,
I
I
do
actually
have
a
question
and
I
apologize
because
it's
a
noob
question
again
I've
heard
on
several
calls
you
mentioned,
and
others
mentioned
the
term
normative
language.
Can
you
expand
what
you
mean
by
that.
B
Yeah
so
normative
language
is.
Whenever
we
say
you
know,
the
words
should
must
or
may,
and
you
know,
there's
a
standard
set
of
of
there's
a
standard
vocabulary,
for
you
know.
Writing
these
types
of
documents
it's
defined
in
a
in
an
RFC
I
can
find
a
link
to
it
at
some
point.
For
you,
but
you
know
normative
language
is,
is
meant
to
basically
say
that
you
know
implementers
of
this
people
who
write
this
API
or
SDK.
B
This
is
things
that
you
know
they
they
need
to
adhere
to
with
varying
levels
of
strictness.
May
should
or
must.
C
B
All
right,
so
if
you
have
comments
on
that,
please
please
engage
with
that
PR
and
or
issue
we'd
like
to
you
know.
This
is
a
nice
segue
into
the
next
issue.
We'd
like
to
declare
the
bridge
API
and
SDK
is
stable,
and
this
question
of
naming
is
kind
of
one
of
the
the
last
minor
unaddressed
things,
and
so
we
just
want
to
put
a
nice
bow
around
that.
B
So
yeah
we're
we're,
you
know,
I,
don't
know
I
think
most
of
you
probably
are
in
cncf
slack,
but
we're
getting
really
close
to
marking
the
bridge
API
and
SDK
documents
as
stable.
So
if
you
have
any
last
comments,
Now's
the
Time
and
that's
a
nice
segue
into
this
last
item,
which
is
you
know,
a
comment
from
Martin
I
see
Martin
you're
on
the
call
Martin
you
were
reading
through
the
the
documents-
and
you
know
you
made
a
couple
of
of
comments
here.
Do
you
want
to
discuss
those
now.
D
Yeah
sure
so
I
was
we
are
in
in
the
process
of
implementing
the
log
SDK
in
the
JavaScript
SDK
and
and
specifically
the
automatic
or
the
implicit
edition
of
Trace
context
to
logs.
D
It
wasn't
clear
to
me
from
reading
the
spec
how
that
should
happen
and
I
think
what
I
think
part
of
it.
That
confused
me
was
this,
this
language
that
says
in
the
processor
on
emit
function.
It
says
that
you
know
the
context.
D
The
context
is
being
passed
through
the
on
emit
function,
but
it
says
that
if
the
include
Trace
context
configuration
is
set
to
false,
then
then
an
empty
context
should
be
added
should
be
passed
into
the
processor,
so
that
confused
me,
because
I
thought
well
is
that
is
the
intent
here
that
the
processor
should
be
where,
where
the
trace
context
is
being
added
me,
you
clarified
check
that.
That's
not
the
case
that
it
should
be.
D
That
should
happen
in
in
the
logger,
but
it
seems
to
me
like
it's
wrong,
then,
because,
as
you
pointed
out,
the
context
can
be
used
for
other
things
than
the
trace,
Trace
context.
B
D
Right
can
you
can
you
clarify
really
quick,
how
context
would
be
passed
in
explicitly
to
a
single
log
record.
B
Yeah,
so
in
the
bridge
API
when
you're
emitting
a
log,
the
arguments
that
are
included
on
a
log
record
are
the
ones
stated
here,
and
one
of
them
is
context
and
contacts
is,
you
know
a
container
of
all
sorts
of
contacts,
one
one
portion
of
which
is
the
trace
context
and.
A
B
You
know
you
should
be
able
to
explicitly
set
that
when
you're
recording
the
log
record,
it
may
not
always
be
appropriate
to
use
the
one
that
is
like
implicitly
available
and
and
then
also
some
languages.
Don't
have
the
support.
The
idea
of
implicit
context.
E
B
E
E
B
B
D
So,
that's
that's
how
we
have
it
implemented
in
JavaScript.
So
far
we
have
the
log
record
interface
from
the
API
just
having
the
trace
context
on
it.
E
B
Maybe
we
should
rephrase
this
just
to
say
then
the
the
the
trace
contacts
like
read,
write
log
record.
You
know.
E
B
E
B
Right
which
relies
on
it
relies
on.
You
know
the
the
processing
happening
on
the
same
thread
that
the
log
record
was
recorded
on
and
it
relies
on
like
implicit
context,
and
so
you
know
if
the,
if
explicit
contacts
was
necessary
to
set
for
some
reason
than
you
know,
calling
baggage
dot
current
would
would
be
incorrect.
B
C
Apologies
for
another
Noob
question,
but
I
see
that
we're
talking
about
like
log
record
processors
and
just
so
I,
don't
get
myself
confused
with
these
terms
when
we're
talking
about
processors-
or
we
also
is,
are
we
also
talking
about
processors
in
the
context
of
wow,
The,
Collector
processors
or
such
as
transform.
B
No,
so
the
processors
in
the
SDK
are
a
little
bit
different
than
the
collector
okay.
It's
in
my
opinion,
a
bit
of
a
unfortunate
that
we'll
use
the
same
word
processor
in
both
in
both
contexts.
But
you
know
they're
they're
much.
C
A
A
B
So,
okay,
Mike
and
Martin.
So
then,
what
do
you
all
think
about
the
proposal?
This
proposal
adjust
read,
write
log
record
so
that
to
make
it
clear
that
only
the
trace
contacts
is
available
on
read,
write
log
record
and
simultaneously
adjust.
B
This
definition
of
the
context.
Argument
for
log
record
processor
to
you
know,
exclude
this
clause
about
an
empty
context.
If
include
Trace
context
was
false.
E
A
B
Well,
I'll
give
that
some
thought
offline
and
I'll
open
the
proposal.
C
So
just
a
a
question
I
know
and
I
know
we
had
sort
of
a
an
offline
exchange
about
the
the
breadth
of
what
the
logs
data
model
covers
and
I
think
Jack.
You
made
a
comment
that
the
that
open,
Telemetry
doesn't
make
any
expectations
about
what
the
output
of
a
log
appender
should
be
from.
B
Yeah,
the
the
log
data
model
covers
two
different
representations
of
the
data,
so
you
know
if
in
any
open,
Telemetry
component,
you
have
like
an
in-memory
representation
of
a
log
record.
B
Then
you
know
the
log
data
model
kind
of
dictates,
the
structure
of
that
in-memory
representation
and
then
the
other
one
is
you
know
if
you're
transmitting
it
over
the
network
using
otlp,
then
the
the
log
data
model
also
governs
the
the
structured
of
log
records
in
otlp,
and
so
you
know
in
this
in
the
use
case
where
you
have
like
an
appender
and
it's
you
know,
writing
logs
to
the
council
and
you
use
something
like
fluentbit
to
to
forward
those
logs
to
somewhere.
B
Well,
if,
if
at
any
point
you
forward
those
logs
to
The
Collector
component,
then
some
software
has
in
in
the
some
some
piece
of
software
in
The
Collector
has
to
you
know,
interpret
that
string
a
message
and
transform
it
into
a
like
a
proper
in-memory
representation
of
a
log
record.
And
you
know,
presumably
there's
parsing
logic
in
there
to
try
to
like,
for
example,
if
it's
Json
extract
key
value
Pairs
and
include
them
as
attributes
and
maybe
look
for
certain
identifiers
of
top
level.
B
C
Model.
Okay,
thank
you
so
so,
in
other
words,
the
logs
data
model
was
never
intended
to
be.
You
know
something
that
it
was
never
intended
to
be
a
standard
that
that
log
appenders.
Should
you
know
if
you're
writing
it
to
a
console
or
a
file
or
something
else
that
they
were
never
really
intended
to
do.
That.
B
Incorrect
with
I
guess
one
kind
of
qualification
to
that.
So
you
know
in
the
otlp
representation
of
the
data
they're,
you
know
the
the
most
common
way
to
use
otlp
is
to
send
it
over
a
network
and
it's
it's
binary
or
Json
representation.
B
But
there's
also
this
idea
of
of
of
like
a
bio
exporter
of
otlp,
where
you
take
otlp
records,
translate
them
to
their
Json
representation,
protobuf
Json
representation
and
you
know,
write
them
to
a
file
where
one
record
represents
one
line
in
the
file,
and
so
you
know
what
you
see
here
is
like
you
know.
B
This
is
the
otlp
Json
encoding
of
a
log
record,
and
so
you
know
it
has
the
the
the
hierarchical
representation
where
you
have
resource
logs
and
then
within
that
are
scope
logs
and
within
that
are
individual
log
records
and
somewhere
down
the
hierarchy.
You
have
an
individual
log
record,
but
this
is.
This
is
not
a
pleasant
way
to,
like
you
know,
emit
log
records
onto
the
console
from
an
application.
It's
like
it's
good
for
machine
readability,
but
it's
it's
really
poor
for
like
an
application
operator.
B
C
B
Appreciate
that
yeah
and
the
event
that
you
did
do
this,
like
you
know
you,
you
had
a
console
offender
or
you
know
that
you
know
encoded
the
the
log
records
in
this
type
of
representation.
It
would
be
very
easy
for
The
Collector
to
interpret
these
lines
and
reconstitute
like
a
perfect
lossless
in-memory
representation
of
the
log
data
model,
but.
B
All
right:
well,
if
there's
no
other
discussion
points,
we
can
end
early.