►
From YouTube: 2022-10-05 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
B
D
B
Okay,
let's
start
where
we
have
there,
the
kubernetes
events,
receiver
Jack,
do
you
want
to
talk
about
it.
C
Yeah
so
I
think
Santos
is
familiar
with
this,
so
he
opened
a
PR
on
the
spec
to
change
the
definition
of
a
vet
name,
remove
the
uniqueness
requirement
of
it
within
a
domain
and
there's
a
link
to
this
issue
in
the
collector
control
repository
where
they
talk
about
mapping
where
we're
talking
about
mapping.
Events
from
kubernetes
and
I
was
just
curious.
C
Well.
So
if
we
look
at
the
issue
in
the
Cooper
in
The,
Collector
repository
and
correct
me,
if
I'm
wrong,
Santosh
but
I
I,
think
that
the
suggestion
is
to
use
something
akin
to
a
high
cardinality
resource
identifier
as
event
names
and
I.
Don't
think
that
that's
a
that's
not
aligned
with
my
understanding
of
what
event
name
is
supposed
to
be,
but
yeah.
D
Yeah
yeah
I,
even
I,
had
a
misunderstanding,
so
it
turns
out
that
kubernetes
events
don't
have
a
name
or
a
type
you
know
built
in
into
the
event
data
model.
So
what
that
PR
refers
to,
as
name
is
actually
the
involved.
Object's
name,
not
the
event's
name,
so
I
realized
it
later
and
so
yeah
I
think
my
PR
may
not
necessarily
apply
but
yeah
I
think
a
couple.
D
So
we
can
introduce
the
language
around
the
name
being
low,
cardinality
I
think
the
spam
names
have
that
in
in
the
description.
So
we
could
add
that
language
to
the
event
name
as
well,
but
I
was
wondering
whether
we
need
to
talk
about
the
name
being
unique
because.
D
And-
and
this
could
be
hypothetical
because
I
was
thinking
that
if
the
original
Event
Systems
that
are
being
mapped
to
that
are
being
represented
in
open
Telemetry,
if,
if
their
names
do
not
have
the
uniqueness
constraint,
then
do
we
need
to
impress.
D
I
think
it
only
means
that
by
just
looking
at
the
name,
you
you
know
that's
sufficient
to
determine
what
it
represents,
whereas
in
the
case
of
kubernetes
events,
my
understanding
when
I
first
read
this
issue,
and
it
turns
out
to
be
wrong-
is
that
the
name
you
can
have
the
same
event
name
across
different
name
spaces
and
and
those
events
could
mean
different
things.
B
D
It
is
something
similar
to
our
domain
right,
so
so
you
know
tomorrow.
If
let's
say
somebody
wants
to
build
custom
events
in
kubernetes,
if
they
want
to
generate
events,
you
know
and
in
their
namespace
they
could
emit
events,
and
you
know
there
could
be
conflicts
or
they
could
reuse
the
names,
but
unintentionally
and
and
they
could
mean
different
things.
B
Yeah,
so
the
purpose
of
our
event
domain
is
to
isolate
different
groups
of
people
from
whatever
decisions
they
make
affecting
other
groups
right
within
their
own
group.
They
can
make
any
sort
of
choices
they
they
can.
They
want
to
make
and
it
may
be
a
poor
choice
yeah,
but
we're
isolating
that
culture
is
to
just
that
domain
right.
That's
that's
the
only
thing
that
I
think
that
domains
are
providing
to
us
and
I
think
that
that's
the
only
thing
that
we're
expecting
them
to
provide
us.
B
You
choose
poor
event,
names
that
don't
reflect
whatever
the
the
semantics
you
use
the
same
name
for
different
different,
actually
different
events.
It's
your
choice,
I
mean
you
did
it
for
in
your
own
domain.
We're
not
going
to
do
anything
about
it.
You
know
complementary.
What
we're
just
saying
is
that
your
choices,
don't
impact
others.
People
who
work
in
other
domains,
I
think
that
that
that's
my
expectation,
that's.
D
How
yeah
and
that's
exactly
what
I
was
thinking
and
and
therefore
I?
You
know
my
in
my
PR
I
removed
the
language
about
uniqueness
of
humanity
within
a
domain
yeah
I.
C
Think
I
think
with
that
said,
we
could
offer
some
more
guidance
about
the
types
of
things
that
make
good
event
names.
So
the
idea
in
my
head
is
that
events
that
have
the
same
domain
and
name
are
structurally
similar
to
one
another.
That's
kind
of
a
subjective
definition
of
what
constitutes
structurally
similar,
and
so
people
could
come
to
different
conclusions,
but
I
think
the
existence
of
this
conversation
is
kind
of
indicative
that
it's
not
completely
clear
what
an
event
name
is,
and
we
could
offer
some
more
yeah.
B
C
B
E
Does
seem
like
a
really
good
example,
though,
in
terms
of
you
know
in
this
case,
like
what
they're
calling
category
for
no
reason
seems
to
be
what
we
would
call
a
name
and
then
like
what
they
call.
A
name
is
what
we
would
call
an
IB
right,
and
we
can
find
an
example
that
uses
name
as
a
category
which
is
kind
of
what
we're
putting
forward.
So
without
changing
one
of
them.
We're
not
going
to
be
able
to
have
a
semantic,
be
like
a
consistent
semantic
convention.
E
I
mean
in
category
is
a
concept
right
like
so
we've
kind
of
got
event
named
like
as
Jack
said,
like
it
means
a
certain
thing,
has
a
certain
structure
and
is
can
be
you
know
grouped
together
right.
So
it's
a
category
of
things.
That's
that's
just
for
the
conversation.
E
That's
the
name
of
music
right,
so
we're
using
name
as
a
category
of
things
and
kubernetes
is
using
name
as
an
ID,
which
is
something
that
you
know
they're
just
semantically
incompatible,
so
we're
gonna
have
to
figure
out
how
what
we
want
to
do
with
it.
So
we're
going
to
go
ahead
and
rename
this
so
that
it
meets
our
concept.
Or
are
we
just
going
to
pass
through
the
names
but.
B
E
So
it
would
be
dot,
meta
or
metadata.name
would
be
kind
of
the
equivalent
of
you
know
that
that's
what
we,
what
you
would
call
a
pod
name
right,
yeah
right!
That's.
B
B
C
The
idea
of
the
name
is
not
semantically
the
same
as
event
name,
so
what
I
suggested
down
below
was
that
we
use
a
combination
of
two
Fields,
the
involved
objects,
kind
and
the
reason,
and
so
that
would
manifest
in
things
like
deployment
scaling,
replica
set
and
replica
set.
C
You
know
successful,
create
because
these
are
kind
of
change
events.
These
are
changes
that
have
happened
to
resources
in
the
kubernetes
ecosystem
and
each
different
kind
of
resource
is
going
to
have
a
series
of
changes,
a
type
different
actions
that
can
be
performed
on
it,
and
so
I
was
suggesting
that
maybe
that
might
make
sense
is
a
good
event.
B
B
It's
it's
still
like.
Yes,
it's
a
good
starting
point
right.
The
reason
seems
like
semantically.
It
describes
what
happened
right.
Maybe
it's
not
granular
enough.
Maybe
you
want
better
granularity
by
touching
it
with
with
concatenating
it
with
the
evolved
objects.
Kind.
That's
also
a
fine
choice.
I
mean
it's
a
choice.
You
have
to
make
when
you're
doing
this
mapping
right,
yep.
B
C
So
components
related
to
coming
so
the
component
is
the
thing
that
is
executing
the
change,
so
it
detected
some
sort
of
condition
in
the
system
and
is
executing
the
change.
So
it's
the
thing
that
is
actually
making
the
change
yeah.
C
B
Okay,
so
anyway,
I
think
both
of
the
approaches
are
reasonable.
It's
a
choice.
You
need
to
make
choose
the
reason
or
Reason
Plus
the
object,
kind
or
or
maybe
some
others
I
mean
yes,
it's
a
choice
you
need
to
make.
There
is
no,
but
the
the
reason
for
the
event
domains.
Existence
is
to
isolate
domains
from
one
another
within
the
domain.
Whatever
you
do
impacts
only
your
domain,
that's
that's
the
purpose
of
the
domain
other
than
that
I.
Think
I,
I,
like
this
test,
probably
or
maybe
just
the
reason
alone-
also
works.
C
Sounds
good
and
you
know
in
terms
of
adding
some
additional
specific
Clarity
around
the
definition
of
event.
Name
so
I
think
we're
all
kind
of
in
agreement
that
some
examples
or
some
rules
of
thumb
would
be
good.
I
can
well
Santosh
has
an
open,
PR
I'm,
not
sure
what
you
want
to
do
with
that
PR.
In
light
of
this
conversation,
I
will
say
that
the
pr
that
I
have
open,
which
updates
the
log
readme
to
kind
of
bring
it
into
sync
with
our
API
and
SDK.
C
D
Okay,
yeah
I.
Can
what
what
about
the
uniqueness
of
events?
Do
we
want
to
keep
that
text
or
remove
it.
C
C
C
C
C
B
B
D
So
I
can
close
my
PR
and
Jack
in
in
your
existing
PR.
You
can
make
these
changes
yeah.
B
Or
explain
that
unique
really
means
that
events
with
the
same
name
belonging
to
different
domains
are
really
different
events
right.
That's
that's!
Maybe
what
that's
what
we
meant
by
saying
unique,
really
but
yeah
we're
not
we're
not
really
explain
it
properly.
By
just
saying
it's
unique,
unique
within
domain.
C
Yeah
Santosh,
why
don't
you
so?
My
PR
has
been
open
for
a
while
and
I.
Don't
really
want
to
increase
the
scope
and
kind
of
reset
the
approvals
on
it.
So
if
you
don't
mind,
if
you
could
take
a
look
at
the
phrasing
in
my
PR
and
reflect
it
in
the
the
event
semantic
inventions,
I
think
that
would
be.
That
would
be
useful.
Okay,.
A
C
B
B
B
Correct
I,
don't
think
we're
we're
saying
that
there
is
going
to
be
a
semantic
convention
for
a
particular
event
name,
not
necessarily
probably
it's
maybe
a
possibility
for
a
particular,
very
well-defined
domain.
Maybe
you
can
come
up
with
a
list
of
possible
events,
their
names
and
the
corresponding
structure
that
you
expect
for
that
particular
event
name.
But
it
is
not
the
default
expectation,
we're
saying:
kubernetes
events
are
a
domain
or
a
browser
event.
B
A
But
if
you
were
trying
to
look
at
how
to
interpret
the
structure
of
an
event
the
domain
and
the
name
are
the
things
you
need
to
identify,
what
structure
you
should
use
the
the
name
alone
is
insufficient.
Domain
alone
is
insufficient
and
there
are
no
other
key,
no
other
values
that
are
involved
in
deciding
how
you
should
interpret
an
event.
B
B
Let's
say:
I
have
two
events,
connect
and
disconnect
I
need
both
I'm
interested
in
both
connect
and
disconnect,
and
the
way
that
I
know
that
the
event
belongs
to
one
of
these.
It
belongs
to
this
class
of
events,
essentially,
is
by
looking
at
the
at
another
attribute,
which
is
the
source,
IP
and
or
destination
IP.
So
it
depends
on
the
purpose
of
what
what
why
are
you
looking
at
the
event,
so
I
wouldn't
I
wouldn't
phrase
it
the
way.
D
That's
also
the
other
point.
You
mentioned
right
tegram,
which
is
that
in
a
given
domain,
it's
up
to
the
domain
to
follow
best
practices,
so
it
may
not
and
if
they
don't
follow,
which
we
are
not
requiring
them
to
follow,
then
then
the
name
and
the
domain.
They
don't
necessarily
uniquely
identify
the
structure.
C
Yeah,
like
there's
always
the
chance
for
for
folks
to
use
the
apis
to
produce
Telemetry.
That
is
not
in
aligned.
With
the
the
recommendations
we
put
out,
you
can
record
metrics
that
have
really
high
cardinality
and
use
uuids
and
attributes.
You
can
record
high
cardinality
span
names
and
in
a
similar
way,
you
can
produce
events
that
have
event
domains
and
event
names
that
disagree
with
the
advice
we
give.
B
In
case
of
the
logs,
it's
also
a
bit
more
complicated
because
you
can
have
a
source,
a
log
Source
coming
from
somewhere
else,
completely
unrelated
to
open
Telemetry,
and
you
try
to
convert
it
to
to
open
Telemetry
format
right
and
and
then
you
make
a
choice.
What
is
my
event?
Name?
You
choose
a
field
from
somewhere
like
from
your
Source
data
format,
which
looks
reasonable,
but
you
don't
really
control
the
source
format.
B
You
probably
can't
provide
the
guarantees
that
that
particular
field
actually
is
indicative
of
of
the
shape
of
the
other
attributes
of
the
other
data
that
the
other,
the
payload
of
the
event
right.
So
it
can
be
a
good
thing
to
to
to
to
to
to
guide
people
on
when
when
they
are
designing
their
events,
but
it
can't
be
a
requirement
because
it
may
be
a
design
that
was
done
a
decade
ago
right.
B
B
A
C
C
You
know
there
might
be
further
subclassification
of
different
types
of
of
events
that
share
the
same
domain
and
name,
for
example
like
if
you
have
you
know,
events
representing
Clicks
in
the
browser,
maybe
in
certain
contexts
the
clicks
have
a
more
attributes
than
in
other
contexts,
and
so,
like
you
know
that
that
that's
always
true
right
when,
if
you
have
a
database
schema
and
you
define
a
table,
some
of
the
fields
can
be
nullable.
C
D
A
D
A
B
I
mean
yes,
what
sort
of
meaning
are
you
expecting
here?
I
think
the
answer
is
yes,
they
cannot
expect,
but
what
is
it
that
you're?
What
what
kind
of
meaning
you
would
expect
like
being
able
to
group
them?
Yes,
sure
you
can
group
them.
Why
not?
What.
B
D
B
Does
that
even
mean
right
in
a
generic
case?
Like
are
you
writing?
What
do
you
do
with
that?
How
you
deal
with
the
data
is
going
to
be
very
specific
to
The
Domain
and
the
event
that
you're
dealing
with
right.
Are
you
going
to
show
it
in
the
UI
in
some
interesting
way
where
the
visualization
depends
on
the
on
the
kind
of
the
event,
then
you're,
probably
writing
a
specific
code
code
that
is
specific
to
the
type
of
the
event
right.
B
A
B
Fine,
if
you
want
to
do
that,
because
you're
designing
your
events
right
exactly
you're
the
author
of
The
Design,
that's
great!
Do
that!
That's
nice
right!
Uniformness,
consistency,
that's
excellent!
But
if
you're
a
receiver,
a
generic
receiver
that
is
not
designed
specifically
for
Ram,
for
example,
then
don't
make
an
assumption
like
that
right
and
in
that
it's
unclear.
If,
if,
if
you
make
that
assumption,
what
do
you
do
with
that?
Like?
Does
it
help
you
to
do
indexing
of
the
fields
with
the
storage?
Somehow
I
guess
maybe
it
could
like?
B
A
A
B
Okay,
I
think
we
needed
PR
that
clarifies
all
this.
Does
anyone
want
to
take
it
because
I'll.
B
B
You
probably
saw
it
and
the
The
Proposal
there
didn't
allow
passing
the
context
with
the
logging
functions
which
made
it
difficult
to
then
fetch
the
spam
context
and
and
and
include
the
span
ID
and
Trace
ID
in
the
in
the
log
records.
So
there
was
this
interesting
proposal
about
how
to
overcome
it.
Essentially
dynamically
allowed
to
to
to
fetch
that
context.
B
So
let
me
actually
post
the
link,
it's
easier
to
see
the
code
than
to
explain
the
idea.
So
I
just
wanted
to
validate
seems
like
it's
a
good
idea,
but
I
guess
I'm
asking
maybe
people
who
are
familiar
with
gold,
whether
they
think
it's
a
good
idea
or
no,
it
seems
like
it's.
It's
doable.
It's
workable
I
was
wondering
for
some
opinions
there
as
well.
B
B
So
we
we're
in
in
our
logging
spec
we
say
that
in
languages
with
the
explicit
context
passing
go.
For
example,
you
have
to
explicitly
pass
the
the
trace
context
as
well.
That's
the
spam
context,
but
with
this
solution
you
don't
really
need
to.
If
you
passed
the
genetic
context,
the
ghost
context.
That's
that's
good
enough
right,
then
we
will
be
able
to
fetch
the
spam
context
in
our
open,
Telemetry
Handler.
The
opportunity
backend
for
this
goal
goes
logging
new
new
logging
API.
So
that's
that's
a
nice
thing.
I
think.
E
A
The
proposal
here
is
that
when
you
pull
it
out
to
make
a
callback
on
the
logger
that
you've
pulled
out,
providing
it
the
current
context
that
it
was
just
pulled
out
from
because
it
may
have
been
passed
along
through
several
context,
changes.
B
A
B
A
B
Time
so
the
the
you
implement
the
context
Handler
in
your
your
logging
Candler,
essentially
the
login
Handler.
If
it
implements
the
contact
sampler,
then
it
allows
you
to
essentially
so
in
in
my
implementation,
I
I
pull
the
the
spam
context
in
the
Handler.
If
you
want
to
see
the
the
code,
I
can
very
quickly
do
that
as
well
hold
on
a
second.
Why
is
that
I
had
it
somewhere
in
my
implementation.
A
Yeah
I
think
that's
a
good
start.
The
thing
that
worries
me
about
that
is
potentially
what
happens
when
the
current
context
changes,
but
you
pass
along
the
logger
divorce.
From
that
context,.
B
B
That's
that's
yeah
that
you
should
not
be
doing
that.
The
idea
here
is
that
you
always
get
a
context,
the
regular
goals,
context
and
whenever
you
need
to
to
do
a
logging
operation,
you
always
fetch
the
logger
from
the
context,
so
it
has
to
become
sort
of
a
best
practice.
How
do
where
do
you
get
the
logger
from
don't
don't
store
it
in
the
structures,
always
fetch
it
from
the
from
the
context?
Essentially,
this
this
implies
it
right
this.
This
part
of
the
Sense
part
of
the
the
entire
proposal,
essentially.
A
B
A
B
Yeah
you
authorize.
The
entire
proposal
falls
apart
that
it
depends
on
that
anyway,
so
essentially,
with
the
open
currency
Handler.
This
is
the
implementation
right.
You
get
the
span
context
from
the
from
the
from
the
code
context
and
create
a
new
Handler
with
that
spun
context,
and
now
in
the
Handler,
when
you
have
to
when
you
handle
the
record
you
you
now
have
a
stand
context
right.
You
essentially
can
use
the
trace,
ID
and
span
ID,
so
it
seems
like
it
should
work
so
in
in
the
user
call.
B
It
looks
like
like
this
right
like
a
regular.
What
is
it
yeah?
You'll
start.
You
start
a
span
which
then
gives
you
a
context.
You
pass
that
context
to
whoever
is
doing
some
other
inner
work
and
you
get
the
logger
from
from
that
context,
and
you
log
the
record
here
and
it
just
works
correctly
in
this
case
it
it
logs
that
Trace
ID
and
span
ID
properly.
A
B
A
I
would
look
at
going
the
other
way
so
that
you
could
do
things
like
modify
attributes
on
the
span
or
inject
events
into
the
span.
You
can
always
yeah
now,
if
you
lose
the
context
and
just
store
the
span
contacts,
you
can't
get
back
to
the
span,
but
if
you
store
the
span,
you
can
always
get
the
span
context
out
of
it.
B
Yeah
here
you
mean
in
the
context
here:
yeah
yeah.
B
A
I
think
this
is
great
and
I
would
love
to
be
able
to
start
trying
to
build
out
an
implementation
for
this.
Do
we
have
any
expectation
for
when
this
might
actually
be
the
real
thing?
Are
we
looking
at
it,
which.