►
From YouTube: 2022-08-24 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
B
A
Okay,
let's
start
the
first
one
is
about
elastic
common
schema,
plus,
open
clementry.
Who
wants
to
talk
about
this?
I
I'm
guessing
elastic
forks.
You
guys
added
it
to
the
agenda.
E
Yeah,
hey
tigran
nice
to
meet
you.
My
name
is
jamie
hines.
I'm
the
product
manager
responsible
for
elastic
on
the
schema
joining
me
today
is
mike
paquette
and
martin
who's.
Also
from
elastic.
Am
I
correct
in
saying
taker
that
you
were
involved
in
the
original
proposal
which
I've
linked
in
the
agenda?
I
see
your
name
either.
E
So
back
earlier
this
year,
as
you
can
see
at
the
date
and
the
proposal
back
in
february,
there
was
a
proposal
for
hotel
to
adopt
it
as
the
common
schema
and
there
might
have
been
some
github
issues
raised
and
even
some
pr's
and
but
it
hasn't
really
gained
much
traction
or
progress
ever
since,
and
we
wanted
to
join
the
special
interest
group
today
to
assess
where
things
are
at
with
regards
to
ecs
and
hotel
and
how
we
can
collaborate
from
here
and
discuss
some
next
steps.
E
A
Yeah
this
proposal
was
discussed
in
this
particular
sig
a
few
times,
and
mostly
there
was
consensus
consensus
around
the
fact
that
we
do
want
something
like
this
to
happen,
and
the
result
of
that
was
the
this
document
was
written,
it
was
reviewed
and
then
it
was
turned
into
an
all-tap.
I
added
the
link
to
the
alt
app
to
the
to
the
meeting
notes.
A
Now
this
is
the
logging
sig
we
are.
We
are
primarily
working
on
the
part
of
the
open,
telemetry
specification
which
is
related
to
logs
the
the
proposal
is
bigger
than
that.
It's
not
just
about
logs
it.
A
It's
about
semantic
conventions
which
apply
which,
which
are
applicable
across
open
climate
change
right,
and
so
this
requires
bigger
consensus
right
the
so
I
I'm
personally
supportive
of
this.
I
think
a
lot
of
people
in
the
logging
seat
previously
also
expressed
their
support.
A
What
needs
to
happen
now
is
a
broader
discussion
and
acceptance
of
the
of
the
proposal
right
it,
the
pro
that
the
puzzle
is
there.
I
think
a
few
people
saw
it
and
commented
on
it,
but
it
it
wasn't.
I
think
it
wasn't
circulated
widely
enough.
So
what?
What?
A
What
you
guys
need
to
do
to
make
it
successful
is
to
is
to
increase
the
visibility
of
of
the
proposal,
talk
to
talk
to
people
who
have
a
saying
in
this,
which
would
be
all
of
the
specification
approvers
in
particular,
but
also
other
people
who
who
may
have
an
interest
in
improving
the
semantic
conventions
in
general.
So
the
the
right
setting
to
to
to
do
these
discussions
would
be
the
specification
seek.
First
of
all,
I
mean
it's
fine
to
discuss
here
as
well.
That's
that's
okay,
but
it
is
not
enough
right.
A
A
On
on
on
the
otap,
you
can
mention
the
github
user
group,
the
spec
specification
approvers,
so
us
ask
for
reviews
there.
But
and
again
it's
not
enough
right.
You
need
to
do
more
to
raise
the
awareness
of
the
proposal.
Ask
for
feedback
for
reviews.
It
will
be
a
process.
A
Hopefully,
I
guess
no
one
objects
to
it
and
then
once
the
otep
gets
accepted
the
step
after
that,
and
my
understanding
is
that
the
auth
as
it
exists
or
the
proposal
as
it
exists,
it's
more
often
a
declaration
of
an
intent
right.
This
is
what
we
want
to
do,
but
it
doesn't
include
the
specifics
of
how
exactly
it
happens
right.
So
that
would
be
a
step
after
that.
A
I
I
can
imagine
that
likely
the
the
intent
is
acceptable
to
the
community
it,
but
I
mean
everything
is
possible,
but
it's
hard
for
me
to
imagine
that
people
would
not
want
to
have
richer
set
of
semantic
conventions
at
open,
telemetry
and
ecs
is
already
an
established
set
of
conventions.
That
would
be
very
nice
to
borrow
from
so
once
the
intent
is
acceptable
for
for
people
who
have
a
saying
here.
There
is
a
required
number
of
approvals
that
you
need
to
have
on
what
app.
I
think
it's
four.
A
Then,
after
that,
I
expect
probably
you
guys,
because
you
are
proposing
it
will
need
to
start
making
submitting
new
pull
requests
against
the
open,
telemetry
specification
to
other
particular
semantic
conventions
and
whether
that
happens
wholesale
or
piecemeal,
probably
piecemeal.
Maybe
I
guess
because
very
large
prs
are
are
very
hard
to
review
and
they
take
a
very
long
time
to
get
nurse
so
that
that's
that's
the
step
after
that
right,
so
we're
we're
at
the
first
step.
Yet
that's
that
that
needs
to
happen
first,
and
I
feel
like
that.
A
A
E
Right
thanks
to
the
guys
and
stickers,
to
be
honest,
we
weren't
exactly
sure
where
to
go
next
and
that's
why
we
said
we
put
it
with
the
log
sig
first
and
we're
unsure
how
to
I
guess,
discusses
a
broader
community.
So
I
wasn't
even
aware
there
was
a
specification
sig
as
well
so
yeah.
Thanks
for
the
guidance
there,
we'll
certainly
kind
of
broaden
the
scope
better
and
tag
those
spec
approvers
in
the
github
issue
as
well.
A
Yeah
yeah,
I
mean
nothing
wrong
with
starting
here,
that's
fine!
We
have
people
here
who
actually
have
a
saying
in
the
matter,
but
the
next
steps
would
be
with
the
specification
forks
and
actually
we
had
a
discussion
earlier
today
in
the
technical
committee.
It
is
likely,
I
would
say
it's
possible
that
there
will
be
there
will,
will
create
a
new
work
group
specifically
to
provide
guidance
about
semantic
conventions,
so
that
may
help
as
well
right
we
have
we.
A
We
feel
that
we,
we
lack
some
some
help
here
for
for
people
who
do
want
to
contribute
new
semantic
conventions.
There
is
lack
of
guidance,
general
guidance
about
how
to
do
that,
so
that
may
help
as
well.
But
I
wouldn't
wait
for
that
to
happen,
but
that
may
be
a
long
process,
so
we
should
we
should.
You
should
still
continue
moving
forward
with
the
proposal
that
you
have.
E
Sounds
good?
Are
there
any
particular
areas
you
think
in
the
the
current
schematic
conventions,
where
there's
gaps,
we'll
say
that
if
we
are
to
do
kind
of
piecemeal
ecs
adoption,
as
you
call
it,
where
you
know
the
certain
fields
that
ecs
maybe
has
that
you
really
are
lacking
today?
Is
there
any
kind
of
priorities
there
in
terms
of
what
fields
you'd
like
to
focus
on
initially.
A
It's
hard
to
tell,
I
don't
know
the
auto
conventions.
Are
they
cover
much
smaller
set
of
topics?
The
acs
is
much
broader.
I
don't
know
which
of
the
ones
that
hotel
is
missing
are
the
ones
that
will
be
the
least
controversial
like
the
easiest
to
get
accepted
and
hard
to
tell
from
the
top
of
my
head.
Maybe
I
can
maybe
can
think
about
it.
I
don't
know
if
others
have
any
thoughts
on
this.
E
If
not
no
problem
and
there's
obviously
some
kind
of
logistical
items
that
we
would
again
have
to
discuss
more
broadly,
but
and
if
you
cast
your
mind
back
the
original
proposal,
how
did
you
see
it
playing
out
in
terms
of
ecs
and
hotel?
Was
it
that
we
can
give
you
permission
to
use
ecs
fields
in
hotel?
Or
did
you
imagine
a
situation
where
we
donate
ecs
to
hotel,
or
was
there
any
discussions
back
earlier
this
year
in
terms
of
the
the
actual
logistics
of
how
ecs
nodes
have
to
work
together?.
A
The
logistics,
I
think,
should
be
that
some
of
you
from
elastic
will
need
to
will
need
to
prepare
the
conventions
in
the
form
that
is
mergeable
to
open
telemetry,
which
is
not
not
necessarily
exactly
that
in
the
form
that
ecs
exists.
There
is
a.
There
is
a
number
of
differences
there.
One
is
that
in
ecs
the
conventions
are
defined,
hierarchically
right
and
in
open
telemetry.
We
use
the
dot
notation
to
reflect
the
hierarchic
nature.
So
I
guess
there
is
this.
A
Based
on
that,
so
you
would
probably
take
the
the
definition
of
the
the
dcs
in
whatever
form
it
exists
today
and
turn
it
into
yaml
files
that
we
can
then
put
into
the
open,
telemetry
specification
repo
and
generate
the
markdowns
from
there.
A
But
an
important
part
of
that
work
is
figuring
out
which
of
the
conventions
that
ecs
has
also
already
exist
in
open
telemetry,
and
you
would
need
to
so
based
on
the
proposal
that
you
you
you
have
there,
you
would
need
to
remove
the
portions
from
the
ecs
that
are
conflicting
with
with
the
open
telemetry
and
the
rest
for
the
rest
of
the
decision
needs
to
be
made.
A
Do
they
remain
exactly
as
they
are,
or
anything
needs
to
be
adjusted
so
that
it
is,
is
more
consistent
with
what,
with
the
rest,
that
it
exists
at
open
climate
right.
So
some,
maybe
small
adjustments
are
going
to
be
necessary.
I
hope
not
right.
I
hope
that
there
is
no
need
to
do
a
lot
of
adjustments,
so
I
I
don't
want
to
end
up
in
a
situation
that,
when
you
have
to
rework
recreate
all
of
that
that
work
that
has
been
done
for
so
many
years
on
ecs
right,
you
will
just
end
up
it.
A
I
I
know
how
hard
it
is
to
produce
these
sort
of
things
right.
I
want
to
reuse
what
what
exists
already
in
the
form
that
exists
with
the
smallest
number
of
changes
possible,
but
some
changes
are
inevitable
right
because
we
have
a
few
things
that
are
already
defined
at
hotel,
that
we
cannot
change
and
which
also
exists
at
dcs.
So
the
conflict
resolution
approach
that
we
we,
I
think
we
agreed
on-
was
that
the
the
the
the
ones
that
exist
in
open
telemetry
take
precedence.
A
Luckily,
there
is
a
very
small
number
of
those,
so
the
majority
of
the
ecs
conventions
likely
can
remain
as
this,
so
that
that
would
be
the
the
way
I
see
the
process
right
submit.
The
pull
request,
with
a
yaml
of
a
particular
probably
area
in
ecs
and
have
it
approved,
get
merged
becomes
part
of
the
open,
20
specification.
But
again
this
is
we're
talking
about
steps
after
the
the
step,
the
first
step,
which
is
when
the
intent
is
accepted
by
the
by
the
community.
D
A
So,
do
you
guys
need
any
more
any
more
guidance
about
how
to
approach
the
specification
seek
or.
E
A
Yeah,
absolutely
that's
fine
and
and
and
use
as
many
channels
as
as
possible.
Right
also,
posting
slack
continue.
The
discussion
on
github
mention
people
who
you
know
who
you
engaged
previously
with
like,
so
somebody
had
an
opinion
in
the
zoom
meeting
about
whatever
aspect
of
this
proposal
try
to
engage
with
them,
also
after
the
meeting
on
github
right.
So
it
helps
to
kind
of
be
persistent
on
multiple
fronts.
Here.
E
A
Yes,
yes,
it's
a
well-defined
process
on
the
ops.
You
need
to
have
a
certain
number
of
approvals,
so
literally
approved
approval
of
the
pull
request
which
which
the
vote
app
represents,
and
once
you
reach
the
the
formal
number
it's
I
believe
it's
four
for
the
autopsy
for
from
official
approvers,
so
it
has
to
be
specific
people.
Others
can
improve
as
well,
which
is
good.
It
shows
that
there
is
interest.
There
is
larger,
I
guess
acceptance
by
the
community,
but
you
need
for
approvals
from
from
specification
approvers.
A
E
D
No
thank
you
super
super
helpful
for
that
context,
so
we
appreciate
your
accommodation
of
our
requests
and
for
the
guidance
you've
provided.
Thank
you.
A
E
D
And
look.
B
B
So
jack
suggested
making
the
language
consistent
in
the
sdk
so
jack.
I
think
there
is
an
open
pr
from
you
on
the
log
processor
mutation.
B
C
Yeah,
I
think
so.
The
the
change
that
I
make
made
has
the
required
number
of
approvals.
I
think
so.
I
think
it's
ready
to
be
merged.
Okay,
and
so
I
I
imagine
that
these
changes
happen
kind
of
sequentially,
so
the
the
pr
to
for
the
event
and
log
api
can
be
merged
independently
of
the
tr
that
I
have
open
to
allow
log
processors
to
mutate
logs
and
then
as
a
follow-up
for
that,
we
can
make
the
language
consistent
between
the
sdk
and
the
api.
A
C
Yeah
log
emitter
versus
log.
A
Yeah
yeah
yeah,
it's
fine!
I
think
it's
fine.
We
don't
have
to
block
one
for
the
other
or
vice
versa.
That's
fine!
We
can
merge
them
in
parallel.
I
I
did
my
my
I
guess
final
review
of
the
of
your
pull
request.
Santosh
and
I
I
approved
it.
I
made
some
some
minor
editorial
suggestions
there,
but
I
think
it's
ready.
You
just
need
to
make
merge
emergency
because
anyway,
it's
it's
a
it's.
It's
a
draft
anyway
right!
It's
it's
marked
as
an
experimental
document.
A
Let's
anyway,
I
encourage
everyone
else
to
to
review,
review
it
and
hopefully
approve,
and
we
can
manage
it
and
move
forward.
Okay,
I
don't
think
we
have
any
other
log
approvers
today
in
the
call,
but
I
will
ping
everybody.
I
think
I
did
ping
already.
If
not,
I
will
ping
so
that
I
can
do
a
review.
Yeah,
yeah
sure.
A
Cool,
that's
all
we
have
in
the
agenda.
What
else.
D
I
probably
just
have
a
question
for
you
tigran,
so
this
is
around
the
nested
attribute
clarification,
spec,
pr
that
I
opened
quite
a
while
ago.
Now
it's
getting
loads
of
pushback,
the
last
ones
from
christian
is
saying.
The
way
this
should
be
clarified
is
to
go
and
clarify
as
a
separate
log
attributes
which
I'd
prefer
not
to
do.
A
What
okay,
so
if
there
is
an
objection
on
the
pr,
I
guess
there's
two
ways
to
move
forward
right.
You
either
agree
something
there
or
if,
if
I
guess
that
the
the
last
thing
that
you
can
do
is
to
kind
of
make
an
official
request
for
for
a
dc
member
to
make
a
call
there
right.
If
you
believe
we're
there,
I
can
take
a
look
at
it.
A
D
No,
it's
more
a
way
of
I'm
not
looking
for
intervention
at
this
point.
It
really
is
a
case
of.
Is
there
another
angle
to
come
at
this?
I
I
dropped
the
the
pr
in
there
in
the
thing,
like
I
I've
all
the
previous
objections.
I
think
I've
addressed,
but
this
one
I
I
can't
see
an
easy
way
to
address
it.
A
D
So
really
I
I
started
this
out
by
saying:
oh,
let's
define
the
attribute
specification,
so
it
matches
the
protobuf
specification
and
then
also
tried
to
take
into
account
some
of
the
other
nested
attribute
discussions
in
issue
376..
D
This
is
now
just
boiled
down
to
just
try
and
clarify
and
unify
the
attribute
spec
with
the
products
spec.
But
christians
come
back
in
a
couple
of
different
ones,
saying
well,
the
proto-spec
is
just
the
protocol,
it's
just
the
what
is
on
the
wire
and
I've
gone
yes,
but
in
terms
of
the
when
people
go
to
implement
this
rather
than
introduce
a
completely
separate
type,
I
log
attribute,
which
is
what
he's
now
wanting
us
to
do.
D
It's
it's
more
a
case
of
I'm
just
trying
to
like
the
wording.
I've
got
in
the
spec
talks
about
that.
If
an
exporter
doesn't
support
nested
attributes,
they
should
have
a
and
the
word
just
escape
me
a
method
to
convert
and
make
it.
So
it
works
because
it's
quite
possible
that
you
get
other
implementations
and
there's
about
to
be
one.
That's
going
to
get
added
to
javascript
contract
repo
in
the
coming
weeks,
where
they
don't
use
any
of
the
hotel
classes
at
all.
D
They
just
actually
create
the
otlp
payload
directly,
so
it's
quite
possible
that
they
could
actually
implement
it
and
have
nested
attributes.
So,
therefore,
any
downstream
thing,
that's
processing.
Those
attributes
needs
to
be
aware
and
needs
to
handle
it
in
a
common
way,
which
is
what
I'm
trying
to
to
have
it
defined
as.
A
D
Because
it
is
right,
yeah
that's
gone
through
several
iterations
of
clarification.
Let's
see
if
I
can
find
the
table
and
I'll
drop
a
link
into
that
there.
It
is.
D
Go
away
to
that
one,
so
this
is
the
table
that
in
the
pr
assuming
that
actually
pasted
the
one
with
the
line,
links
that
calls
out
whether
it's
supported
or
not
yeah.
A
D
A
A
The
specification
doesn't
need
to
require
that
or
prohibit
that
it
can
be
a
decision
that
is
made
by
every
every
language
implementation,
whether
it's
an
ex
it's
logs,
extending
the
the
basic
attributes
or
it's
a
separate
data
type
again.
I
I
don't
think
we
really
require
the
specification
to
go
into
that.
What
I
think
is
missing.
You're,
absolutely
right
that
it
is
missing,
is
an
explicit
allowance
that
the
log
attributes
can
be
nested,
so
that
part
definitely
needs
to
be
resolved.
A
I
think
the
part
that
that
that
christian
is
objecting
to
is
that
maybe
somehow
it
it
relaxes
the
the
current
restrictions
that
we
placed
on
the
tracing
and
metrics
attributes.
That
probably,
is
what
he
is
objecting
to.
A
D
Yeah
it
would,
it
probably
was
a
little
wishy-washy
in
the
first
instances,
but
in
the
current
one
I
it's
really.
This
table
is.
A
A
C
And
just
one
comment
on
that,
so
that
pr
you
know,
there's
that
table
that
you
called
out.
That
indicates
whether
complex
or
nested
attributes
are
supported
by
each
signal,
but
they
also
apply
to
resources
as
well.
You
might
want
to
note
that
you
know
I
guess
I
I
would
assume
that
we
don't
intend
resources
to
have
nested
attributes
as
part
of
this
change.
B
So
in
the
specification
report
there
is
a
document
on
telemetry
stability
that
marks
an
instrumentation
as
a
stable
or
unstable.
B
B
Because
the
library
could
have
bugs
you
know
it
could
still
be
evolving,
but
the
data
that
it
emits
the.
B
It's
well
the
the
intent
is.
The
purpose
is
different.
I
think
the
idea
is
we
will
reach.
Definitely
we
will
have
to
wait
until
there
is
minimum
maturity
of
the
library
too,
but
there
will
be
a
point
where
the
library
is
used
by
it's
a
shared
library.
B
It
will
be
used
by
multiple
different
instrumentations
and
therefore
it
could
take
a
longer
time
to
to
you
know
being
stable,
but
for
some
of
the
instrumentation
packages
that
you
know
are,
are
you
know
close
to
you
know
being
in
a
final
state
in
afar
for
the
content
that
they
produce,
the
the
library
could
have
bug
fixes?
B
It
might
not
be
handling
all
the
corner
scenarios,
but
if
we
mark
the
telemetry
as
stable,
then
it
could
you
know
we
could
add,
I
mean
basically,
it
could
allow
changes
that
are
acceptable
under
you
know
the
defined
conditions
of
the
stability.
A
A
Yeah,
maybe
you
can
have
that
clarification
in
the
language,
because
I'm
reading
it
right
now
it
says
all
open,
telemetry
author,
the
instrumentations
are
labeled
to
be
either
unstable
or
stable
from
the
perspective
of
the
telemetry
they
produce
right.
It
says
from
the
perspective
of
the
telemetry
it's
it's
essentially
it
says
that
it's
a
distinct
aspect
of
stability
of
every
library,
yeah.
B
But
if
you
go
to
the
status
page
of
the
open,
telemetry.io
website,
you
know
for
for
each
of
the
languages,
I
think
for
each
of
the
instrumentations.
I
think
there
is
a
you
know,
stabler
and
stable.
So
I
think
these.
A
Are
two
yeah
because
it
stages
it's
when
you
look
at
that,
it's
a
stability
of
the
sdk,
not
instrumentations,
we
don't
have
the
stability
of
instrumentations,
I
think
anywhere
on
the
website.
There
do
we
like
individual
instrumentations,
because
this
is
about
each
specific
instrumentation
library,
not
the
sdk.
B
And
a
related
topic
was
for
for
a
given
event
for
different
types
of
events.
We
also
want
to
define
what
are
the
expected
attributes.
B
I'm
wondering
how
to
go
about
that,
because
the
semantic
conventions
today,
you
know,
does
have
the
required
the
requirement
level,
but,
but
it
doesn't
say
it's
required
under
what
context
in
in
what
so
for
the
same
attribute
could
be
used
in
multiple
locations
in
in
in
a
span,
or
you
know,
in
in
a
different
log
record
of
a
certain
type
of
a
certain,
even
type.
A
I
don't
think
so.
No,
it's
english
pros
everywhere,
like
it
describes,
what's
the
condition
and
when
the
the
attribute
is
expected
to
to
to
be
there,
so
you
want
some
sort
of
formally
defined
way
to
specify
the
structure
of
the
event
and
you
want
it
to
be
also
checked
programmatically
at
the
time
of
generation.
I
guess
is
that
what
you
want.
B
Both
it
will
serve
dual
purpose
at
the
time
of
generation
and
also
for
the
consumers
to
validate.
A
B
So
how
do
the
different
instrumentation
teams,
the
different
language
teams?
How
do
they
arrive
at
what
the
different
instrumentations
generate?
Is
that
is
there
a
path
to
stability?
There.
A
Client
you're
supposed
to
follow
the
conventions
for
http
clients
which
are
generic
they
are
across.
They
are
language,
independent
right,
so
you're
supposed
to
follow
that.
If
you
have
something
very
specific
to
your
language,
then
it's
probably
not
regulated
in
the
semantic
conventions.
Right
now,
most
most
of
language,
specific
things
are
not
some
small
amounts
are
there,
but
mostly
not.
A
B
Okay,
yeah,
maybe
I
I
I'm-
I
don't
have
the
question
clear
in
my
mind:
yeah
so
yeah
I'll
ask
later:
okay.
D
Yeah
maybe
another
way
to
phrase
this
is,
I
know
jaymac
so
josh
mcdonald
was
talking
about
having
the
signal
level
using
the
schema
url
to
version
it.
I
think
this
is
the
same
type
of
thing,
but
at
the
event
type
level
effectively
you
know
instrumentation
level
which
yeah
I
I
don't
think
the
schema
url
has
happened
yet
in
terms
of
full
discussion,
and
I
don't
think
it
that's
different.
Just
said,
I
don't
think
this
is
this
exists
at
the
instrumentation
I.e
the
event
level
at
this
point.
B
A
Okay,
okay,
cool
anything
else.
Anyone.