►
From YouTube: 2022-06-22 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
C
A
Okay,
let's
start
so,
I
missed
the
the
last
week's
meeting
and
I
see
you
guys
did
have
the
meeting
which
is
great.
Is
there?
Is
there
any
carryovers
from
the
last
week's
meeting
that
we
need
to
continue
discussing.
C
A
Cool,
so
let's,
let's
let's
go
with
the
agenda,
then
I
see
you
have
an
item
there
jack.
You
want
to
talk
about
the
problem
that
you
saw.
E
Yeah
sure
so
in
java
we
have
been
talking
about
implementing
a
log
processor
that
can
selectively
extract
data
from
context
and
include
it
on
on
the
log
data,
and
I
think
some
of
the
the
design
of
the
sdk
right
now
is
kind
of
making
that
a
bit
challenging.
So
you
know
the
interface
of
a
log
processor
is:
is
this
just
this
emit?
So
you,
you
emit
a
log
data
to
the
log
processor
and
you
know
kind
of
how
we
were
imagining
doing.
E
This
is
chaining
together,
multiple
log
processors
or
registering
multiple
log
processors.
So,
first
you
have
one
that
extracts
your
relevant
context
and
then
that
data
gets
passed
to
maybe
the
batch
log
processor,
so
it
can
get
exported,
and
so
that's
that
type
of
setup
is
isn't
really
possible
today,
because
well,
log
data
is
immutable,
and
so
you
can't
you
can't
really
change
it
in
a
log
processor,
and
so
that's
one
of
the
problems
and.
A
So
do
we
do
we
want
this
so
that
that
becomes
the
way
that
the
user
chooses,
whether
that
the
context
is
included
in
the
log
records
or
no,
or
is
it
as
another
way
that
the
user
can
control
this
functionality?
A
Because
I
remember
we
were
talking
about
this
being
an
option
when
you
obtain
the
logger,
not
a
separate
log
processor,
when
you
obtain
the
logger,
when
we
remember,
I
think
we
we
talked
about
having
an
option
when
you
with
a
with
a
get
logger
when
you
say
whether
to
include
or
not
include
the
the
context
in
the
produced
log
records.
E
E
You
know
the
sdk
section
of
of
logging
so
that
I
think
that
was
discussed
at
the
at
the
api
level
for
somebody
who's.
You
know
writing
logs
through
the
api.
A
Right
so
when
so,
I'm
looking
at
the
rtap
the
events
and
logs
api
or
tab
there
is
this
one
of
the
one
of
the
parameters
to
get
the
logger.
D
A
The
are
you
thinking
about
having
this
log
processor
as
an
implementation
detail
that
you
set
up
when
when
this,
when
this
this
parameter
is
enabled
or
is
it
something
alternate,
I'm
I'm
not
sure.
I
understand
what
the
intent
here
is
so.
E
It's
not
just
trace
context,
it's
it's
context
in
general.
So
if
you're
using
the
general
context
mechanism
to
like
propagate
data,
then
you
know
the
use
case
is
to
that.
You
want
to
selectively,
extract
bits
of
that
context
and
include
them
on
your
log
data,
and
you
know
it's
not
really
important,
where
that
it's
important,
that
it's
like
an
sdk
configuration
thing.
E
So
you
know
you
you,
you
don't
want
to
configure
this
at
the
api
level,
but
you
know
if
this
could
happen
either
in
a
a
log
exporter
or
in
a
log
processor.
Those
are
kind
of
the
two
extension
points
that
might
make
sense.
You
can't
do
it
in
an
exporter
as
it
stands
today,
because
the
log
data
doesn't
carry
with
it
its
context.
A
E
A
F
F
The
reason
I
ask
is
in
the
net
sdk
we
just
made
everything
mutable,
because
we
had
users
asking
basically
for
the
feature
they
wanted
to
build
like
scrubbing
processors,
and
some
people
want
to
do
it
in
the
exporter.
So
it's
not
blocking
like
the
log
path,
the
hot
path,
so
we
tried
a
few
different
things.
Ultimately,
we
just
made
everything
publicly
settable
just
to
unblock
everyone.
Will
we
be
out
of
compliance
with
the
spec
if
we
ship
that.
E
E
And
that
doesn't
mean
you
can't
mutate
it
you
just
have
to
like
you
just
kind
of
have
to
you
know.
Have
it
like
a
delegation
pattern
where
you
create
like
a
new
instance
of
the
the
the
log
data
and
delegate
to
the
existing
one
and
and
replace
or
change
whatever
fields
you
need
to
change.
E
Have
to
copy
you
can
just
delegate,
so
you
can
just
keep
a
reference
to.
A
G
F
A
F
F
F
We've
seen
on
the
implementations
that
I've
seen
are
actually
done
at
the
export
time,
so
it's
more
or
less
asynchronous
to
the
logs
being
generated,
which
is
even
weirder.
I
feel
like
by
the
spec.
The
processor
is
the
place
to
do
it,
but
then,
if
you're
scanning
you're
mutating
you're
running
regex's,
then
all
your
logs
are
kind
of
delayed.
So
you're,
you
know
delaying
your
actual
logic
that
you
need
to
get
done.
F
A
E
This
kind
of
was
fallout
from
or
just
carry
over
from
the
trace,
sdk
and
so
yeah.
We
would
need
that
context,
trying
to
remember
what
the
repercussions
of
that
are.
A
Okay,
let's,
let's
let's
try
to
figure
it
out,
why?
Why
is
it
so
in
in
trace
and
traces?
Maybe
there
is
a
good
reason
that
we
we
don't
know-
and
maybe
that
is
applicable
or
not
applicable
to
logs
right
and
then
we'll
decide
from
there.
F
Maybe
just
more
likelihood
of
stuff
sneaking
into
logs,
it's
maybe
less
likely
with
traces,
because
you're,
just
you
know,
what's
in
the
semantic
conventions,
isn't
really
sensitive,
I
mean
you
can
get
stuff
on
the
query
string.
We
have
seen
users
reporting,
they
want
the
ability
to
massage
you
know
the
path
and
sometimes
the
span
name.
So
there's
definitely
some
cases
that
are
emerging
that
are
interesting.
E
Okay-
and
I
I
guess
the
other
thing
that
kind
of
is
related
to
the
mutability
of
logs-
is
just
how
the
the
log
processor
works
so
in
in
in
the
span
world
you
have,
the
span,
processor
has
a
on
start
and
an
on
end,
and
so
you
know,
if
you,
if
you
imagine,
having
multiple
span
processors
present,
you
know
you
call
and
a
span
comes
through.
E
You
call
each
of
their
onstart
methods
sequentially
when
the
span
is
started
and
then
when
the
span
is
ended,
you
call
each
of
their
on-end
methods,
sequentially,
and
so
the
processors
have
the
ability
to
like
influence
the
other
processors,
because
they
can,
they
can
have
behavior
on
their
onstart
implementation
in
the
onstart
method
that
you
know
other
span
processors
see
later
when
on
end
is
called
because
you
know
you
can
mutate
spans
to
some
extent
onstart.
E
So,
but
you
know,
logs
only
have
this
one
method
emit,
and
so
you
know,
if
you
imagine,
multiple
log
processors
being
present,
they
just
have
this
emit
method
which
doesn't
return
anything
it
just
returns.
It's
just
a
void
response,
and
so
they
actually
don't
have
any
ability,
as
it
stands
today,
to
influence
subsequent
processors.
Unless
you,
unless
you
like,
you,
have
a
delegation
pattern
where
you
have
like
one
processor
that
wraps
another.
But
that's
you
know
that's
different
than
how
span
processors
work.
A
A
A
C
Yeah
now
I
just
wanted
to
discuss
about
the
next
steps.
I
think
one
of
the
reviewers
commented
daniel.
I
think,
commented
that
a
good
part
of
the
hotep
you
know
is
ideally
suited
for
a
spec
yeah.
So
there's
a
lot
of
api
interface
description,
that's
mentioned
here.
C
Are
we
violating
the
guidelines
for
an
autumn
here?
Do
you
want
me
to
move
that
out.
C
What
was
the
objection
from
daniel?
You
said:
yeah
yeah.
I
think
he
mentioned
that
the
detailed
description
about
the
api
interface
itself-
you
know
it
doesn't
have
to
be
in
the
otp.
Whatever
is
is
more
to
make
a
case
that,
whether
you
know
why
we
need
this
api
and
then
the
api
interface
itself
you
know,
could
could
be
more
to
the
you
know,
spec
report,
which
I
think
we
need
to
do
anyways,
so
I'm
wondering
whether
we
should
keep
a
copy
or
just
remove
it.
Yeah.
A
We
need
this
in
the
spec.
Definitely,
obviously
whether
we
need
it
in
the
old
tap.
I
think
it
doesn't
hurt
to
have
it
there,
it's
more
precise.
In
a
sense,
and
in
the
past
we
did
have
autops,
which
were
very
very
specific
and
when
we
then
later
literally
just
copy
paste
it
from
the
otap
to
the
spec,
I
mean
it's
fine,
either
way,
if,
if
you
want
to
delete
it
from
the
otep
just
to
make
sure
that
it
moves
forward
faster,
that's
fine!
I
don't
see
this.
A
This
is
a
bloker
to
be
honest,
either
way
next
step
for
me
is,
I
guess
we
may
make
sure
that
all
of
the
comments
on
the
authep
are
resolved
and
we
we
get
it
approved
and
start
adding
stuff
to
the
specification,
essentially
copying
from
the
op
into
the
specification.
A
A
That's
that's.
That's
the
yeah,
that's
the
rule.
I
guess
I
don't
think
we
were
even
able
to
merge.
If
there
is
any
outstanding
comments
there.
I
think
there's
okay,
it's
blocked
from
merging
okay,
so
I
see
there's
a
bunch
of
open
comments
anyway.
So
if
you,
if
you
believe
that
you
you
answer
them,
they
don't
require
any
further
discussion,
just
resolve
them
and
if
whatever
remains,
but
let's
see
what
remains
right.
If,
if
there
is
any
any
that
are
blockers,
then
we
will
need
to
discuss
and
and
just
remove
the
blockers.
A
I
don't
think
dylan's.
So
sorry,
I
don't
think
daniel's
comment
is
he's
a
blocker
he's
just
more
like
editorial
comment
about
what.
Why
is
it
in
the
opera
yeah.
C
A
C
Okay.
Okay,
that's
that
and
another
thing
is
on
the
events.
So
it's
a
new
topic
on
the
events
attributes
that
we
have
event.name
and
event.domain
that
we
described.
C
The
I
I
want
to
submit
a
pr
on
the
spec
to
introduce
those
semantic
conventions.
Do
we
can
I
go
ahead
with
that
before
even
this
whatever's
much
so
that
I
can
start
getting
feedback.
A
I
think
let's
wait
for
the
otap,
it
comes
as
a
package
right
as
a
whole
and
the
the
semantic
conventions
are
essentially
proposed
in
this
authentic
right.
You
you,
the
first
time
we
we
saw
this
semantic
conventions
is
here
in
this
software.
Once
it
is
approved,
you
can
then
submit
the
essentially
you
can
make
it.
Probably
it
can
be
one
pr
can
be
multiple
pr's
again
the
specification
which
bring
the
autop
into
the
spec,
so
the
the
semantic
we
we
do
have
a
semantic
convention
section
for
logs
right
already
in
the
spec
one.
F
A
A
B
And
I
I
had
actually
one
related
question
to
this-
that
we
also
discussed
in
the
client
side
sig,
which
is
we
are
introducing
the
concept
of
this
event.
Name
event
domain
and
the
semantic
conventions
will
be
around
like
for
for
each
individual
event
type.
There
will
be
a
set
of
semantic
conventions,
which
is
a
little
bit
different
to
how
some
of
the
conventions
work.
Now,
where
you
have,
you
know
you
have
the
namespace
attributes
and
you
can
compose
them,
so
we're
basically
saying
like
there
now
will
be
in
a
domain.
B
You
have
a
number
of
named
events
and
there
will
be
semantic
conventions
tied
to
those
does.
That
does
does
that,
something
that
we
need
otep
or
clarification
in
maybe
in
this
old
tab,
because
it's
a
little
bit
of
a
change
in
how
symmetrical
engines
are
defined.
A
It
may
require
an
autop
to
make
it
clear.
I
think,
trying
to
modify
this
auto
to
bring
that
into
the
autop
may
delay
this
one
right.
I
would
like
to
move
forward
and
have
at
least
to
get
the
ball
rolling
right
in
the
spec.
Have
this
as
a
draft
added
the
api
added
to
the
spec,
and
then
we
can
work
on
the
semantic
conventions.
Do
the
clarifications
that
you
were
talking
about
and
why
we're
deviating
from
the
the
existing
approach?
A
B
A
I'm
worried
that
it
will
take
even
longer
to
make
sure
that
people
outside
this
sikh
who
are
not
aware
of
those
discussions
are
aligned
with
that
vision
and
if
we
just
do
that
in
one
authent,
that
autop
is
going
to
stay
there
for
many
many
months.
That's
that's
what
I'm
worried
about,
and
I
wouldn't
want
that
to
happen.
So,
let's
just
try
to
break
it
down
into
some
smaller
incremental
deliverables,
to
the
specification
there
and
to
the
people
outside
this
cig
as
well
right,
that's
kind
of
it's
it's
going
to
be
a
process.
C
To
me,
thank
you
yeah.
I
I
want
to
understand
the
contents
of
this
new
type
that
you're
talking
martin.
Are
you
suggesting
that
that
you
you
want
to
define
that
for
each
event
type
you
you
want
to
specify
what
are
the
other
required
or,
generally
you
know
the
other
attributes
that
are
generally
associated
with
that
even
type.
Is
that
what
the
rotep
is
about.
B
Yeah,
I
think
it's
just
a
clarification
on
how
the
semantic
conventions
for
events
are
defined.
A
For
the
existing
semantic
conventions,
martin
is
saying
the
existing
ones.
They
are
groups
of
unrelated
attributes,
essentially
right.
Every
every
entity
that
we
have
in
semantic
conventions
is
a
set
of
attributes
and
there's
no
overlap
in
the
name
of
the
attributes
between
different
groups.
In
this
case,
for
the
for
the
for
the
events,
the
event.name
and
event.domain
is
going
to
be
present
in
every
every
group,
right
essentially
you're
going
to
be
repeating,
and
that
is
new.
That
is
kind
of
unusual.
A
You
don't
see
that
anywhere
else
in
the
existing
semantic
conventions.
I
still
think
it's
valid
it's
the
approach
that
we
agreed
on
all
of
us,
but
if
we
introduce
it,
it
probably
will
require
clarifications.
Why
we're
doing
this
right?
What's
the
reason
and
it
may
in
that
case
it
may
it
may
warrant.
Having
its
own
note
up,
I
think
that's
what
you're
saying
martin
right.
C
A
A
C
Okay,
no
I'm
I'm
actually
trying
to
understand
if
it
is
beyond
these
two
attributes
as
well,
because
in
a
in
an
event
you
know
for,
for
the
for
the
client
side
generated
data,
we
want
to
do
some
validation
on
the
receiver
side,
data
validation.
C
Which
you
know
which
a
validator
would
use
is:
is
that
also
an
intent
for
this
new
tip
that
we're
talking
about.
A
The
author
wouldn't
be
about
specific
attributes
that
you
would
use
right.
It
would
be
about
the
approach
where,
where
it
is,
okay,
that
different
people
making
different
proposals
about
different
semantic
conventions
from
different
areas
actually
refer
to
the
exact
same
attribute
with
the
same
name,
event.name
or
event.domain,
we
should
explain
why.
Why
is
it
okay
to
do
so?
A
G
Yeah
so
santosh
to
link
that
back
to
our
previous
discussions.
It
would
define
the
shape
of
what
an
event
looks
like.
C
C
G
Well,
as
I've
said,
the
other
one
in
the
case
of
I
I
my
preference
would
be,
we
define
an
event
as
the
domain,
the
name
then
the
the
data,
if,
if
the
event
needs
data
open
question
about
whether
we
need
type
and
custom
data,
so
in
fact
we
say
an
event.
Semantic
conventions
is
those
two
to
five
fields,
and
then
we
have
another
thing
saying,
and
this
particular
combination
of
the
main
event
name
expects
the
following.
G
So
in
the
case
of
martin's,
w3c
definition
of
all
the
timing,
events,
we're
saying
you
know
a
a
timing
event
for
this-
must
should
contain
these
other
fields.
I
think
the
level
of
validation
or
the
way
we
define
the
semantic
conventions.
For
that
specific
event,
it's
probably
different
to
where
we
define
it
for
the
general
semantic
conventions
today,
because
it
is
a
case
of
its
event
specific.
So
it's
a
combination
of
that
domain
and
event,
name.
G
Okay,
so
that
we
can
build
it,
you
know
dynamically
and
and
then
they
can
optionally
install
the
validator,
because
I
think
you
don't
necessarily
want
to
have
that
every
time
or
you
only
want
minimal
validation.
A
Yeah,
well,
I
think
we'll
have
an
opportunity
to
discuss
this.
Let's,
let's
get
the
the
the
api
autop
approved
and
then
we'll
deal
with
the
the
semantic
conventions.
C
G
Guess
I've
got
the
next
one,
which
is
really
just
the
the
follow-ups
from
the
previous
discussion
that
we
talked
about
effectively
the
nest
attribute
requirement.
So
I
had
the
the
spec
issue
raised
for
a
couple
of
weeks
now
and
this
week.
Well,
since
the
last
meeting,
I've
created
the
the
pr
which
is
listed
there,
so
I
tried
to
keep
it
fairly
generic
and
I
tried
to
express
what
is
a
what
you
can
do
today,
rather
than
defining
any
changes,
so
I
don't
believe
there's
any
breaking
definitions
in
there.
G
It's
just
a
case
of
well
protobuf.
Lets
us
do
this
so
defining
that
attributes
can
do
that
because
you
can
and
they're
all
the
may.
It's
you
know
you
don't
have
to
have
nested
attributes,
so
I
tried
to
take
the
combination
of
the
you
know
the
the
comments
in
my
spec
pr,
as
well
as
the
link
376,
which
has
been
open
for
a
while
into
account
to
perfectly
come
up
with
the
wording.
That's
there.
G
G
A
I
think
it
just
links
to
here.
So
if
you
delete
this,
if
you
lift
the
restrictions
here,
essentially
you're
allowing
the
implementations,
the
open,
telemetry
implementations
to
begin
sending
data
that
includes
nested
attributes
yeah
if
the
back
yeah,
if
the
back
end
does
not
expect
that,
then
that's
essentially
a
problem
for
that
particular
back
end.
G
Yeah
and
that's
that's
the
key
word
there
that
that
particular
back
end,
which
is
why
I
in
the
spec
in
the
pr
I
tried
to
say
at
the
exporter,
so
I've
sort
of
said
this.
The
signal
I
think
the
span,
the
exporter
or
the
back
end
so
effect
at
any
one
of
those
levels
it
can
implement
whatever
it
needs
to
implement
to
to
handle
this,
whether
including
dropping
it
on
the
floor
if
it
doesn't
handle
it.
G
I
think
I
call
that
a
they
implement
whatever
strategy
they
need,
whether
that's
completely
flattening
out
the
keys
and
making
it
huge,
converting
it
to
json,
which
was
already
indirectly
inferred
as
part
of
an
attribute.
If
it
wasn't
the
perimeter
of
an
array
or
dropping
so
that's
yeah,
I'm
sure
I'll
get
comments.
G
And
I
would
be
surprised
if
it
gets
approvals,
as
is
without
people
complaining
about.
I
I
I
doubt
I'm
not
going
to
have
to
update
it.
G
Yeah,
yes,
I
I
think
friday,
so
I'm
just
starting
to
spread
it
around,
so
I
didn't
bring
it
up
in
the
spec
meeting
this
week.
I
thought
I'd
give
another
week.
It
did
get
allocated
to
sergey,
so
I
think
sergey
hasn't
been
around
for
a
bit
so,
and
there
was
a
discussion
in
the
spec
meeting
this
week
about
that
with
another
pr,
so
we
will
see
how
we
go.
I
will
continue
to
be
the
squeaky
wheel.
This
tip
like
to
describe
it
as.