►
From YouTube: 2023-01-25 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
B
D
I
can
been
a
while,
since
he
hasn't
been
here
so
okay.
D
Well,
let's
look
at
the
first
issue
here:
Tyran
linked
to
the
issue
opened
by
Alan
Alan.
Do
you
wanna,
maybe
take
us
through
this.
E
I,
don't
I
am
curious.
What
is
on
tigran's
mind
here,
but
generally
speaking,
yeah,
this
issue
I
opened
up
a
little
while
back
kind
of
posing
the
question.
If
we're
just
about
ready,
tigran's
added
additional
check
boxes
remaining
issues
in
just
the
past
week,
namely
for
you
know,
making
sure
that
we
have
references
to
working
prototypes.
So
we've
got
Java
and
python
represented
there.
I'm
from
the.net
Sig,
Mike
Blanche
is
also
on
the
call.
He
actually
did
those
prototypes
for
net.
E
I
think
that
there's
still
a
couple
of
PR's
that
I
have
open,
they're
kind
of
further
down
that
list:
3002
and
28
61
they're,
just
some
like
configuration
PRS.
E
E
You
know
that
we're
ready
to
stabilize
the
log
signal
but
I'm
guessing
that
tigrant's
question
for
this
meeting
is
to
just
kind
of
pose
the
question:
do
we,
the
logsig
have
any
other
items
that
we
feel
are
necessary
to
address
prior
to
maybe
having
that
conversation
with
a
larger
community
I,
don't
personally,
but
I'm
I
think
it'd
be
good.
If.
A
F
Do
we
have
anyone
else
from
java
concerning
Jackson
parental
leave,
because
that
would
be
another
input
into
this.
A
E
The
most
part,
at
least
you
know
like
more
full-time,
though
Jack's,
my
colleague,
so
he
and
I
have
discussed
things
pretty
extensively
and
I'm
fairly,
confident
in
representing
that.
He
too
feels
like
this.
Is
this
list
here
is
pretty
much
it
I,
don't
I,
don't
think
that
he
would
have
anything
to
add
to
this
list.
C
E
Yeah
Jack
is
one
of
the
first
peeps
to
put
out
a
prototype
built
on
top
of
the
the
log
API,
and
he
felt
like
it
was.
It
was
the
right
thing
for
his
log
for
Jay,
upender
and
I.
Think
log
back
and
I
think
there
was
another
and
I
think
he'd
it
sounded
like
in
the
in
the
the
conversation
in
the
Java.
Sig
specifically
was
just
kind
of
the
concerns
that
we've
just
we've
discussed
here.
Quite
a
bit
is
just
you
know,
concerns
about
like
hey,
you
know.
Is
this
logging
API?
E
Let's
make
it
real
clear
that
this
is
not
open,
Telemetry
trying
to
invent
a
new
logging
API.
This
API
is
for
the
express
purpose
of
you
know,
being
able
to
create
Integrations
like
these
appenders
and
I
I
got
the
impression
that
his
conversations
with
the
javasig,
the
the
remainder
of
the
Sig,
was
pretty
satisfied
with,
where
things
had
gotten
to
and
clarifying
that.
That's
not
what
we're
doing
so.
D
Great
so
I
think
the
call
to
action
here
is
just
for
everyone
to
give
a
little
bit
more
thought
to
whether
there
should
be
anything
else
on
this
list
and
then
short
of
that
I
mentioned
that
you
know.
Maybe
next
week
we
can
discuss
with
tigrant
next
steps.
D
D
Right,
Santosh,
you
want
to
take
the
log
record,
ID
yeah.
B
I
have
two
topics:
the
first
one
is,
you
know
not
so
big
I.
Think
briefly.
I
think
this
is
in
follow-up
to
a
PR,
introducing
an
ID
for
lock
records,
I
realized,
even
events
would
need
an
ID,
and
would
we
want
to
have
to
separate
conventions
for
logs
and
events
separately
are
just
one
if
if
there
is
any
way
to
you
know
avoid
the
log
prefix,
you
know
that
would
be.
You
know
great.
Otherwise,
you
know
it
is
also
okay
to
have
you
know
event.id
and
log
dot
record.id.
F
B
Know
separately
so
not
a
big
deal,
but
any
quick
thoughts.
B
Or
I
can
just
let
the
pr
take
its
course.
C
B
I
think
it
I'm,
it
looks
like
the
spear
is
not
going
to
get
merged
anyway
soon,
so
let
it
take
time
then
I
have
another
topic.
B
There's
more
of
a
you
know:
I
I
want
to
get
feedback,
whether
I'm
thinking
in
the
right
direction.
I
want
to
give
an
overview
of
you
know
my
further
understanding
of
cloud
events.
B
So
last
week,
I
joined
another
sick
meeting
on
messaging,
where
there
is
one
representative
from
cloud
events.
So
I
had
a
discussion
with
him
on
what
exactly
Cloud
events
is,
and
you
know
where
we
need
to.
You
know
collaborate
if
at
all-
and
my
conclusion
is
that
you
know
we-
we
can
completely
ignore
Cloud
events
for
our
purpose,
but
there
are
some.
B
You
know
good
things
about
the
way
they
have
structured
things
that
we
might
borrow
some
ideas.
So
I
want
to
give
a
a
short
overview
of
cloud
events.
So
would
that
be
okay.
B
So
so
I
like
this,
you
know
piece
of
text
here
describing
Cloud
events.
B
You
know,
Cloud
events
is,
is
an
abstraction
for
events.
You
know
it's
similar
to
how
you
know
VMS.
You
know
you
pick
VMS,
because
you
want
to
pick
your
Hardware
later.
Similarly,
you
know
you
pick
kubernetes,
because
you
want
to
pick
your
provider
later
and
so
even
Cloud
events
is
a
protocol,
agnostic,
representation
of
events-
and
you
know
that
way.
You
know
you
can
standardize
how
the
events
are
represented
and
different.
You
know
protocols
like
let's
say
Kafka
or
IBM
mq
any
of
them.
B
You
know
you
can
adapt
to
those
later
by
the
consumers
and
there
are
even
Eventing
platforms.
You
know
that
are
built
entirely
on
cloud
events,
so
Cloud
events
also
have
a
format.
B
They
have
two
modes,
a
structured
mode
and
a
binary
mode
in
the
structured
mode.
They
have
a
Json
representation
currently
where
they
have
four
mandatory
Fields.
You
know
these
these
last
four
are
the
mandatory
attributes
and,
and
then
the
the
original
payload
goes
into
Data.
B
So
when
you
are
converting
the
idea,
is
you
know
when
you
want
to
exchange
your
events
with
a
consumer
on
a
different
messaging
provider?
You
you
want
to
convert
them
into
a
cloud
events
compliant
format,
and
in
that
case
you
would
pick
a
few
items
from
your
original
event.
Put
them
into.
You
know
these
four
attributes
and
then
put
the
original
event
under
data
and
and
this
data
could
be
of
you,
know
any
content
type
and
which
could
be
represented
using
the
content
type.
B
B
How
you
know
different
events
are
represented
using
Cloud
events
so,
for
example,
an
S3
event
or
an
SNS
event.
You
know
how
it
is
represented
using
Cloud
events
they
have
described
here
so
with
this.
I
am
concluding
that
even
in
our
case,
you
know,
given
that
we
cannot
have
our
events
directly
in
this
native
Cloud
events
original
format.
You
know
we
will,
since
we
are
going
with
log
records,
we
will
need
you
know
if
at
all
in
future.
B
If
anybody
wants
our
events
to
be
consumed
by
consumed
through
Cloud
events
specification,
then
there
needs
to
be
adapted
which
converts
our
events
into
Cloud
events,
and
we
could,
at
that
point
you
know,
Define
a
mapping,
so
I
think
it's
safe
to
completely
ignore
Cloud
events.
B
For
now
we
have
been
talking
about
it
last
few
meetings
you
know
briefly,
but
based
on
my
current
understanding,
I
I
think
it's
it's
entirely:
okay,
to
completely
ignore
Cloud
events
and
and
in
future,
whenever
we
feel
the
need
to
transform
our
events
into
a
cloud
events
compliant
format.
We
we
could
come
up
with
this
mapping
any
questions
so
far.
B
Yeah
yeah
there
are,
there
are
definitely
a
few
things
that
we
could
borrow,
but
my
my
point
is
like
our
original
entire
event
would
would
go
under
you
know.
We
have
two
options.
You
know
I
put
down
a
couple
of
options:
yeah,
you
know
we
can
either
put
the
entire
event
or
pick
only
the
even
data.
The
problem
with
option.
One
nav
is
that
it
doesn't
include
the
timestamp.
That's
that's
the
only
failed.
B
F
Yeah
well,
I
I
would
prefer
option
one
obviously
and
I
would
really
really
at
some
point
in
the
future
like
to
have
data
schema,
also
as
a
top
level
attribute,
so
that
we
could
then
Define
what
event
data
looks
like
right
now,
because
log
records
only
support
nested
attributes,
not
a
generic
any.
You
can't
do
that.
So
that's
why
my
current
PR
doesn't
have
data
schema
listed.
It
only
has
the
domain
name
and
data.
B
Yeah
yeah,
no,
that's
the
second
part
now
I
think
maybe
I
I
shouldn't
have
said
completely
ignore,
but
what
I'm
meant
was
we
we
don't
have
to
you
know.
Maybe
we
could
just
borrow
some
ideas
from
from
them,
but
the
the
way
we
will,
our
events
will
become.
Cloud
events
is,
is
through
an
adapter
where
we
Define
them
mapping.
B
Then
there
will
still
be
some
confusion
because,
even
in
our
case,
we
there
we
go.
B
Did
that
go
yeah,
so
this
is
a
sample
event
that
we
came
up
with
where
an
event
has
an
even
domain
event
name
and
even
data.
Even
data
is
the
the
payload
and
any
metadata
kind
of
an
attribute
we
come
up
with
will
be
at
the
top
level
and
the
payload
will
be
under
data.
So
any
let's
say
you
want
to
have
an
attribute
to
indicate
the
the
payload
schema,
so
that
would
be
at
the
top
level
saying
event
dot
schema.
B
But
when
you
convert
that
whole
event,
when
you
put
that
whole
event
object
into
Data
you
you
would,
you
know
there
would
be
the
schema.
B
Cloud
event
schema
would
represent
the
entire
data,
including
the
and
and
not
just
the
event.data,
whereas
our
our
events
schema
would
refer
to
only
event.data.
So
there
could
be
some.
B
So
so
never
I'm
thinking
I'll.
Let
me
know
what
you
think
I
think
we
can
go
ahead
along
the
lines
we
are
already
discussing,
which
is
we
we
introduce
event.data,
but
then
any
high
level
attributes
have
to
be
explicitly
defined
in
the
semantic
conventions,
and
the
API
should
not
allow
adding
attributes
at
the
top
level
unless
it
is
part
of
the
agreed
semantic
convention,
so
they
have
to
be
metadata.
B
You
know,
that's
one
way
to
you
know:
do
it
another
way?
Is
you
know,
since
now
we
can
leave
it
open,
but
then
the
the
problem
will
be
that
you
know
people
will
definitely.
F
Yeah,
it's
like
logs
and
metrics
today,
like
the
apis,
don't
block
users
from
adding
their
own
attributes
right
and
I.
Don't
think
we
want
to
code
it
in
saying.
Oh,
an
event.data
can't
have
an
attribute
of
this
name
at
the
top
level.
I
just
think
it's
part
of
semantic
conventions.
We
say
an
event,
looks
like
this.
B
But
there
is,
there
is
one
possibility
where,
through
both
the
event,
API
and
the
processors
apis.
F
B
Agree
yeah.
We
could
only
enable
people
adding
attributes
inside
the
event.data.
F
We
can
let
them
add
to
the
top
level
and
as
we're
talking
the
rum
Sig
we
we
should.
F
You
know-
and
maybe
it's
part
of
the
event
data
we
talk
about
in
there,
the
different
data
PR,
you
know
having
the
user
data
to
have
a
top
level
event
that
you
need
to
data
to
let
people
Define
their
own
customers
actually
Morgan.
Do
you
recall
whether
crisis
has
the
ability
for
users
or
a
prefix
for
users
to
add
application,
Level
attributes
of
their
own,
that
semantic
convictions
doesn't
generally
go
undefined.
F
We
just
you
know,
followed
the
same
thing,
so
we
have
a
top
top
level
company
like
this
is
very
Java
specific.
You
come
to
acme.shop
name
but
yeah.
That's
we
have
the
same
thing.
So
it's.
B
F
B
B
G
F
G
Data
is
not
there
yet,
but
right.
E
F
So
to
be
like
event,
event
emit
name
data
and
then
optional,
attributes
which
we
talked
a
lot
attributes.
B
Okay,
but
with
respect
to
abuse,
we
we
just
leave
it
in
any
safeguards.
We
can
no.
F
B
F
But
yeah
there
you
go,
it
will
potentially
contain
other
stuff
like
what
we
just
saw
was
a
com
dot,
something
you
know
the
application
of
the
domain,
especially
sorry
application,
Level
specific
attributes,
and
we
can't
stop
that,
like
it's
part
of
the
logging
API
that
supporters
part
of
the
tracing
API,
it's
supported
by
the
metrics
API
supported.
Why
would
we
block
it
for
event.
B
B
Okay
sounds
good,
so
then
I'll
I'll
update
your
PR.
You
can
introducing
the
changes
to
the
API
where
the
API,
like
the
current
API,
says.
F
Yeah
definitely
I
doesn't
currently
talk
about
the
API.
It
just
talks
about
the
shape.
Sorry,
but
yeah
I
think
if
it
can
reference
the
API
yeah.
That
would
be
good
yeah.
B
I
know
I
was
thinking
that
you
know,
let's
make
changes
to
the
API
as
well,
so
that
that's.
B
Yeah
everything
is
together,
so
the
the
changes
would
be
that
when
you
emit
an
event
you
you
don't
give
a
lock
record
as
in,
but
you
give
two
types
of
attributes,
one
for
data
and
one
for
other
attributes
yeah,
so
that
one
change
I'll
include
in
your
PR.
G
Have
a
quick,
quick
comment
on
this
spec,
since
we
have
it
up.
B
G
Yeah
yeah,
so
we
have.
We
had
a
discussion
from
class
two
meetings.
We
had
discussions
about
separating
or
thinking
about
the
events
API
as
a
separate,
separate
thing
from
the
logs
API,
which
it
is
here,
but
it's
not
necessarily
dependent
on
on
the
like
the
the
event.
Sdk
would
be
an
implementation
using
the
log
log
SDK,
so
I
think
this
spec
and
I
think
needs
to
be
updated
to
reflect
that.
B
Yeah
I
think
there
is
another
issue
or
a
PR
right
where
tigrant
had
a
diagram.
I
think
that
that
needs
to
be
merged.
B
But
I
suggest
you
you
go
ahead.
You
know
whatever
works
for
for
your
implementation
of
events,
SDK,
if
you
are
able
to
do
it
through
log
API,
that's
that's
fine
and
like
Jack
suggested
now
you
might
run
into
issues
with
respect
to
flush
and
shutdown.
So,
in
which
case
you
directly
use
the
log
SDK
and
that's
fine
too.