►
From YouTube: 2023-01-18 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
B
A
That
discussion
about
the
logs
API
versus
events,
API
versus
SDK
and
the
relationship
all
those
things
I
want
to
see.
If
we
can
come
to
a
conclusion
on
at
least
one
of
the
aspects,
whether
we
are
certain
that
we're
going
to
have
a
logs
API
right,
are
we
okay
with
that?
It
is
driven
by
the
needs
of
the
events?
Sdk,
that's
my
understanding,
but
we
don't
necessarily
have
to
agree
right
now.
What
do
we
do
with
the
events?
A
Api
even
say:
SDK
I
am
I'm
more
interested
in
trying
to
move
forward
and,
if
possible,
maybe
stabilize
the
logs,
API
and
SDK
I
wonder
what
people
think
about
this
subset,
I
guess
of
the
discussion,
maybe,
if
possible,.
C
Yeah
I
think
I
think
the
conversation
about
a
log
API
was
partially
steered
by
event
requirements,
but
that
you
know
that
the
log
API
actually
kind
of
it
seems
to
it
seems
to
be
required,
regardless
of
whether
or
not
an
event
API.
So
what
whether
or
not
an
event
API
exists
and
that
event
API
is
dependency
on
a
log,
API
I
think
those
are
tangential,
needs
I
left
a
comment
in
this.
C
This
thread
that's
linked
here
last
week
and
you
know
I
talk
about
it
from
the
perspective
of
writing
a
log
offender,
a
log
offender
which
has
to
take
a
dependency
on
the
the
log
API
in
order
to
bridge
logs
into
open
Telemetry.
It's
just
not
suitable
to
tell
appenders
to
take
a
dependency
on
the
SDK
that
breaks
the
patterns
that
we
tell
instrumentation
authors
to
write
elsewhere,
and
so,
if
we
want
to
be
able
to
write
log
appenders,
we
need
to
have
the
the
authors
of
those
log
offenders.
A
So
to
so
we're
saying,
appenders
or
other
Bridges
should
be
possible
to
be
they.
They
can
be
written
by
Third
Parties
by
instrumentation
offers
not
by
us,
and
they
they.
It
should
be
possible
to
write
them
by
relying
on
just
a
logs
API
and
not
the
logs
SDK
like
we
do
for
other
instrumentation,
and
that
is
the
reason
why
we
need
a
logs
API
right.
Essentially,
that's
that's
what
we're
saying
it
doesn't
have
to
be
tied
with
the
events
API
at
all.
Is
this
a
good
enough
justification
for
all
of
us?
D
A
A
B
Yeah
I'm,
in
line
with
with
John
here
like
there,
should
be
an
event
API.
We
shouldn't
push
it
down
to
the
instrumentation,
like
you
were
proposing,
so.
C
B
B
Simplistically
yeah
it's
a
case
of
while
I
think
Jordan
summarized
that
nicely.
In
fact,
we
happen
to
be
using
the
logs
as
the
transport
mechanisms
for
events,
but
events
aren't
logically
logs
as
far
as
the
applications
are
concerned.
So
from
their
perspective,
they
just
want
to
create
events
and
have
them
sent
to
the
back
end
versus
I.
Think
tigrant,
correct
me.
If
I'm
wrong
on
this,
your
approach
is
saying:
instead
of
creating
an
API,
create,
you
know,
push
it
out
to
the
instrumentation
and
require
the
instrumentation
or
creating
an
event.
B
So
you
think
you
have
event
instrumentations
talk
directly
to
the
logs
API,
which
I
think
is
the
wrong
approach.
A
Yeah,
so
the
specification
disagrees
with
what
you've
said
the
first.
The
first
thing
you
said
right.
The
specification
says
that
events
are
specially
constructed.
Log
records
and
I
agree
with
the
specification.
If
we
think
that
that's
wrong,
then
we
need
to
change
the
specification
if
it
is
in
the
specification
I'm
going
to
go
with
that
right.
So
that's
the
first
part.
A
E
A
B
Yeah
I
think.
The
reason
it
looks
odd
is
because,
rather
than
creating
a
brand
new
event,
transport
we're
transporting
them
with
the
logs
API
I,
think
that's
fundamentally,
where
it
comes
from
and
I,
don't
think
we
I'm
not
promoting.
We
go
down
the
track
of
creating
a
completely
new
transport
for
events.
I
think
that
would
be
the
wrong
approach
as
well
like.
Well,
you
know
for
for
clients,
we
actually
want
to
consolidate
things
a
bit
a
bit
more,
but
that's
a
completely
different
discussion
and.
A
I
think
it's
fundamentally
important
question.
It
is
important
for
us
to
decide
whether
events
are
actually
logs
or
they
just
happen
to
be
transported
using
clothes
for.
B
F
F
B
Yeah
I
I
think
it
it
might
be
a
case
of
as
part
of
like.
Eventually
we
want
all
events
to
be
log
events,
but
as
part
of
a
transition,
it
is
likely
that
someone
may
want
to
effectively
not
break
their
existing
back
ends
and
use
Trace.
B
We're
seeing
we're
going
down
the
logs
path
at
this
point,
but
there
is
already
instrumentations
that
creates
bad
events
today
that
we
want
to
change,
but
there's
gonna
have
to
be
a
migration
path
for
those
and
as
part
of
that
it,
you
know,
and
one
possible
way
to
do
that
would
be
to
create
you
know
a
trace
event.
Sdk,
if
you
like.
F
Yeah
I
think
we
have
to
be
careful
with
that.
That
does
seem
to
be
getting
into
the
territory
that
John
Watson
seems
afraid
of
in
that
we're
conflating
events
and
logs,
because,
in
my
view,
span
events
are
logs
that
are
attached
to
a
trace
right,
there's
little
difference
between
a
log
that
has
a
trace,
ID
and
span,
maybe
attached
to
it
and
a
span
event,
but
events
that
are
used
in
an
event-driven
system
to
indicate
hey.
F
How
are
they
different
from
log
records?
Certainly
some
some
system
could
be
listening
for
log
records
to
come
along
and
treat
them
as
events
in
in
the
sense
of
this
is
a
thing
that
happens.
Take
action
on
it
if
you
want
or
not,
but
I
think
that
those
could
also
be
completely
separate
from
log
records
like
you,
you
could
have
web
hooks,
be
the
the
mechanism
of
transporting
the
fact
that
an
event
occurred
from
point
A
to
point
B
or
you
could
use
some
Pub
sub
mechanism
and
what
goes
on.
F
A
G
C
I
I
think
this
I
was
just
thinking
about
this
I
think
this
picture
might
be
wrong.
I
think
the
event
SDK
might
point
to
the
log
SDK
and
not
the
log,
API
and
and
the
reason
I
think
that
is
because
sdks
have
methods
on
them
that
are
not
available
at
the
API,
namely
shutdown
and
force
flush.
So
what
is
the
SD
event?
Sdk
implementation
of
shutdown
and
or
Force
flush?
Do
it
needs
to
delegate
to
something?
B
I
guess
that
that
comes
down
to
how
many
versions
of
the
log
SDK
like
you,
you
want
someone
to
write
events
that
you
know
they
don't
care
about
what
the
application,
what
version
of
the
log
SDK
the
application
is
playing
with.
So
if
it
takes
a
dependency
on
the
log
SDK,
then
you
start
getting
into
the
version
issues.
C
Now
this
is
just
like
this
is
assuming:
okay
is
you're,
an
application
author
you're,
an
application
operator,
you're
running
an
application,
you
know,
you're,
you
take
independencies
and
a
bunch
of
pieces
of
instrumentation.
All
those
instrumentations
have
dependencies
on
the
apis,
the
log
API,
the
event
API,
the
trace
API
and
the
metric
API,
the
versions
of
those
like
it
does.
You
know
it
doesn't
matter
the
versions
all
kind
of
conflict,
but
they
resolve
up
to
a
common
latest
version
and
backwards
compatibility
ensures
that
they
all
just
work.
C
They
only
had
to
take
one
dependency
on
the
SDK
in
the
application
itself,
and
so
like
one
SDK
artifact
contains
the
log
SDK
the
event
SDK
the
trace,
SDK
the
metric
SDK
and
that
event.
Sdk
version
of
that
has
a
direct
dependency
on
the
log
SDK
within
the
same
versioned
artifact
is
that
does
that
make
sense,
yeah.
F
No,
no
I
I
think
we've
moved
past
that
right.
So
my
initial
concern
was
having
a
log,
API
and
SDK
implementing
both
login
events.
I
think
if
the
event
SDK
exists,
which
kind
of
didn't
really
exist
in
what
we
were
talking
about
before
right,
but
if
the
event
SDK
exists
and
an
implementation
of
that
SDK
takes
a
dependency
on
a
log
SDK.
F
H
H
So
like,
if
you,
if
you
if,
since
the
event
SDK
is
gonna,
have
a
dependency
on
a
specific
version
of
the
log
SDK,
but
you
could
also
register
log
SDK
for
your
logging.
That
could
be
a
different
version.
C
In
Java
we
tell
users
that
having
different
versions
of
the
SDK
like
technically,
we
have
different
artifacts,
so
the
trace
SDK
versus
the
metrics
SDK.
But
if
you
try
to
use
those
in
one
an
application,
we
just
say:
that's
a
bug.
Go
resolve
that
version
conflict.
All
your
SDK
artifacts
should
have
their
versions
aligned
with
each
other
I.
Don't
know.
If
that's
is
that
actually
possible
in
other
languages
to
have
you
know
two
different
versions
of
the
log
SDK
present
in
an
application?
At
the
same
time,.
B
Yeah,
like
one
example,
is
for
a
client
like
on
a
web
page,
especially
here
at
Microsoft.
We've
got
multiple
teams
all
instrumenting
their
own
components,
so
you
do
end
up
with
the
runtime
cons.
You
know,
potentially
containing
multiple
versions
of
the
SDK.
C
B
Oh
because
you've
got
like
the
me
control:
one
want
all
their
logs
and
events
to
go
to
them
the
menu
control
once
all
their
logs
are
meant
to
go
to
them
when
the
application
wants
all
their
logs
in
them.
So
effectively,
you've
got
three
completely
independent
sdks
sending
data
to
three
completely
independent
endpoints.
B
They
could
all
be
completely
separate,
though
this
is
what
I
have
today
like
I'm,
trying
to
unravel
some
of
the
the
issues
that
I
have
on
some
web
pages,
where,
for
our
internal
sdks,
I
can
have
five
different
versions
loaded
in
a
runtime,
and
you
know
this
is
one
of
the
issues.
I
need
to
solve
for
clients
for
otel,
because
the
globals,
because
they
can't
be
the
globals
in
a
client
in
this
case.
F
B
B
You've
got
some
other
application
written
some
of
the
completely
separate
to
Microsoft
goes
and
do
their
does
their
and
it
gets
loaded
with
the
teams.
So
it's
yeah
it's
a
problem.
C
I
guess
the
the
implications
of
what
you're
saying
nav
are
that
SDK
components
can't
have
any
interdependencies
on
each
other
and
I
think
that's
like
a
whole
different
conversation
and
I.
Don't
think,
we've
actually
I
think
it's
actually
unrelated.
F
Yeah
and
I'm
not
sure
if
it's,
if
that's
an
issue,
either
like
if
it's
possible
today,
what
we're
proposing
for
the
event
SDK
would
be
that
you
would
provide
it.
You
know
when
you
construct
an
event:
SDK
instance,
you
handed
a
log
SDK
instance.
So
if
you
can
already
have
multiple
instances
of
the
log
SDK
using
different
versions
of
the
login
SDK,
then
you
could
also
have
event
sdks
that
use
multiple
instances
of
those
at
different
versions.
C
As
long
as
you
have
reasonable
backwards,
compatibility
in
your
SDK
implementations
like
they're,
not
breaking
things,
then
you
know
the
event
SDK
taking
a
dependency
on
a
particular
version
of
the
log
SDK.
It
shouldn't
be
a
problem
if
that
has
to
get
resolved
to
the
latest
version.
A
He
doesn't
even
have
to
get
the
result
to
the
latest
version.
It
has
to
resolve
to
the
specific
version
that
it
was
built
with
right,
because
in
the
scenario
that
map
describes,
they
already
are
able
to
have
multiple
log
sdks
simultaneously,
so
just
just
plug
the
right
log.
Sdk.
To
that
event,
SDK
the
corresponding
version
and
again
I,
don't
see
what
the
problem
is
here
right.
A
You
have
a
pair
of
sdks,
the
log
SDK
and
the
event
SDK
they
match
each
other,
even
if
you,
if
you
even
if
you
change
some
sort
of
internal
API
of
that
SDK
in
a
in
a
newer
version.
Even
that
is
fine
right.
Just
just
make
sure
that
you're
using
the
correct
version
of
the
log
SDK
with
your
event,
SDK
right,
the
one
that
the
event
SDK
requires.
F
F
B
B
B
So
I
think
in
the
thread
we
talked
about
the
construction
of
this,
and
that
was
one
of
the
things
I
think
Jack
that
you
didn't
like
as
part
of
the
event,
the
initial
event
emitter,
having
the
event
emitter
being
passed
down
along
SDK
instance,.
C
And
now,
as
the
the
thing
I
was
concerned,
with
was
if,
if,
in
the
event
API,
you
have
to
pass
it
a
a
logger
provider
in
order
to
obtain
an
instance
of
an
event,
emitter
provider,
then
the
con,
the
caller
of
the
event
API,
has
to
be
aware
of
the
log
API,
and
that
can
conflicts
with
the
statements
that
we
make
about
log
apis
not
being
for
end
users
and
only
being
for
appenders
yeah.
B
C
Yeah
and
and
and
I
think,
the
assertion
is
that
is
that
it's
it's!
It's
not
okay
for
instrumentation
authors
to
have
to
be
aware
of
the
event
API
log
API
relationship,
but
it
is
okay
for
application,
authors
and
operators
to
have
to
be
aware
of
that,
because
you
know
they
have
to
at
some
point
be
aware
that
event.
Events
share
the
log
transport.
D
B
F
To
be
clear
where
the
coupling
would
happen
is
when
you're
constructing
the
events,
SDK
or
the
event
emitter
provider
once
you've
got
that
event:
emitter
provider
you're
using
the
event
API
to
get
event
emitters
out
of
it
and
the
the
user
of
that,
the
consumer
that
who's
the
instrumentation
author
has
no
idea
what
the
transport
is.
It
could
be
logs,
it
could
be
web
hooks,
it
could
be
clubs
of
whatever
correct.
B
F
F
B
B
C
Don't
you
already
have
to
solve
this
in
JavaScript
like
aren't
there
already
shared
components
between
the
sdks
like
resource,
for
example,
like
all
the
all
the
providers,
Tracer
provider
media
provider,
logger
provider
need
to
be
configured
with
a
like
a
resource,
so
that's
got
to
be
in
some
common
place,
and
so
you
know
technically,
you
could
have
two
different
versions
of
the
resource
dependency
on
your
in
in
your
application.
Like
isn't
this
a
like
a
solved
problem?
Well,.
B
It's
dependencies
and
peer
dependencies
and
the
way
npm
what
Packaging
Systems
will
work
is,
if
you
end
up
with
different
components
that
have
different,
have
incompatible
peer
dependencies.
You
will
end
up
with
multiple
versions
in
memory,
because
they'll
get
packaged
separately
and
isolated
in
their
own
closures.
B
C
B
Yep
yeah,
so
if
you
have
component
a
says,
I
have
a
dependency
on
version
1.1,
another
one
that
says:
I
have
a
dependency
on
version
1.2,
if
they're
just
straight
dependencies,
you'll
get
two
different
versions.
If
you
say,
if
both
of
them
say
that
they
have
peer
dependencies
of
any
version,
one
then
I'll
have
to
get
they'll
be
given
the
same
one
during
Packaging.
C
So
then,
the
event
SDK
would
have
to
have
not
appear
to
kind
of
see
a
a
regular
dependency
on
on
a
particular
version
of
the
log
SDK
such
that.
If
there
are
multiple,
you
know
competing
versions
of
the
event
SDK
that
are
present.
They.
B
And
then
you'd
have
two
two
log
sdks
that
would
both
need
to
be
initialized,
because
it's
part
of
the
application,
your
your
application,
probably
says
I
want
the
latest
version.
It'll
go
ahead
and
initialize
that,
but
the
event
one
might
get
initialized,
because
it
was
a
different
version.
C
B
Using
the
logging
API
so
with
the
log
API
there,
then
it's
abstracted
so
effectively.
You
still
still
potentially
have
the
same
problem.
If
the
logging
API
had
breaking
changes,
but
if
the
event
SDK
just
says
I'm
using
a
logging
API
and
if
it's
there,
it
uses
it
and
if
it's
not,
then
effect
ends
up
getting
the
no
op
implementation
and
therefore
everything
would
come
back
down
into
the
same
initialized
instance
of
logging,
SDK.
C
So
I
mean,
couldn't
you
say
the
same
thing
on
the
on
the
SDK
so,
like
you
know,
our
sdks
and
Java
have
really
strict
backwards
compatibility
requirements
so
Konichi
make
the
event.
Sdk
have
a
peer
dependency
on
the
log
SDK
such
that,
like
the
version
gets
resolved
and
there's
a
single
shared
log.
Sdk
present.
If.
B
The
PA
dependency
is
defined
correctly.
That
would
happen,
but
if
the
dependency
is
not
defined
correctly,
then
you'll
end
up
with
multiple
versions
and
it'll
just
work
it'll
just
it'll
just
get
packaged,
but
of
course
nothing
will
happen
because
only
one
instance
will
get
initialized
in
the
application.
C
Something
I
mean
I
kind
of
feel
kind
of
this,
like
I'm,
stating
the
obvious,
but
then
shouldn't
JavaScript
just
properly
declare
the
peer
dependency
between
the
event
SDK
and
the
log
SDK.
Well,.
B
It
gets
so
yes
simplistically,
yes,
they
should
and
I'm
going
to
put,
should
in
quotes,
but
you
could
have
an
instrumentation
that
says:
Okay
I
want
version
two,
because
I
want
yeah
a
version
two
of
the
event
API,
because
we
had
something
spiffy
and
that's
all
I
said
no,
not
compatible,
because
maybe
there's
a
breaking
chain
between
version
one
and
version
two.
And
then
it's
not.
A
B
C
C
On
one
hand,
we
say
the
log
API
is
only
fair
penders,
but
then,
on
the
other
hand,
we
say
that
you
know
instrumentation
authors
using
events
also
have
to
be
aware
of
it,
so
we
can
either
live
without
inconsistency,
or
we
can
say
that
language
ecosystems
like
JavaScript,
that
allow
multiple
versions
of
an
SDK
to
be
present
at
the
same
time,
I
need
to
have
like
you
know
you
need
to
you
know,
have
backwards,
compatibility
such
that
when
they
can
have
this
peer
dependency
and
the
the
log
SDK
dependency
can
be
resolved
to
a
single
version.
B
A
F
Think
right,
I
think
there
needs
to
be
an
event
SDK
precisely
so
that
is
never
have
to
know
anything
other
than
the
event
API
yeah.
If
the
application
author
provides
them
an
implementation
of
the
event
API
through
whatever
event
SDK
they've
initialized
and
the
application
author
then
knows
how
to
connect
the
event
API
to
whatever
its
transport
is
yeah.
B
C
A
Again,
the
question
is
whether
this
goes
to
the
web
SDK
or
goes
to
the
log
API.
That's
that's
the
question
so.
H
D
A
H
C
I'm
happy
enough
with
that,
because
I
know
what
Java
would
do,
but
you
know
I
think
eventually,
you
know
you'll
have
to
you'll
have
to
cross
that
road.
Yeah.
B
And
it's
okay,
so
in
a
client
environment
the
event
SDK
will
need
a
flush
because
during
you
know,
page
unload
is
going
to
have
to
react
unless
we
just
say
it's
completely
passed
through
and
therefore
it's
the
logging
SDK
limitation.
That
does
the
flush,
because
it's
already
received
the
events
to
be
backed
so
yeah.
It's
a
valid
argument.
F
Yeah
lambdas
will
require
the
ability
to
flush
as
well,
but
that
gets
to
a
bigger
problem
of
not
having
the
ability
to
flush
through
instrumentation
and
Linda.
Hager
is
being
instrumentation
and
there
are
all
sorts
of
issues
there.
But
that's
not
our
problem.
A
Okay,
for
the
sake
of
time,
we
should
probably
move
to
the
next
one.
I
will
create
a
separate
issue
to
discuss
that
particular
choice.
We
need
to
make
for
the
events
as
decay,
what
it
depends
on
on
the
log
SDK
or
the
log
API,
but
I
think
we
all
agree,
at
least
on
one
thing:
I
think
it's
important
that
there
is
going
to
be
a
logs
API,
which
is
which
will
be
called
by
the
appenders
and
all
the
others
who,
for
whatever
reason,
need
to
do
that
direct
call.
A
G
A
So,
let's,
let's
move
to,
we
have
two
other
items:
Santosh.
E
E
You
know
what
cloud
events
is
about,
so
I
raised
a
request
in
their
GitHub
an
issue,
and
then
somebody
came
back
saying
they
are
already
joining
the
messaging
Sig
and
wanted
some
of
us
to
you
know
come
there,
so
we
could
discuss
things
and
as
part
of
the
discussion
you
know
they
also
mentioned
in
the
comment
which
I'm
trying
to
understand
what
it
means
that
I.
E
At
one
point
we
said
you
know
we
could
even
consider
using
Cloud
events
API
and
not
have
an
events
API
in
Hotel,
so
in
in
general.
If
we
you
know,
I
was
thinking.
Maybe
we
should
understand
what
is
the
overlap
between
the
two
specifications
so
that
we
we
make
sure
you
know
they
align,
but
instead
I
think
a
Doug
from
cloud
events
is
saying
you
know
there
is.
You
know
we
should
not
consider
Cloud
events
as
an
even
format.
E
You
know
its
purpose
is
to
expose
existing
given
data
in
a
common
location.
E
So
I'm
wondering
if
more
folks
are
interested.
You
know
they
could
join.
You
know
tomorrow's
messaging
Sig
it's
at
8am,
Pacific
time,
but
I
think
it
looks
like
you
know
in
future.
If
there
is
a
need
to
turn
hotel
events
into
Cloud
events,
you
know
we
we
might
have
to
define
a
mapping,
but
otherwise
there
isn't
much
to
consider
with
respect
to
Cloud
events.
For
now.
C
What's
your
take
Santosh
on
this
comment,
that
was
specifically
the
part
that
says.
C
It's
best
not
to
think
of
cloud
events
as
an
event
format
or
anything
so
prescriptive,
just
about
how
to
expose
existing
event
data
in
a
common
location.
What
location!
What's
that
a
reference
to.
E
Yeah
I'm
not
100,
clear,
but
I,
I
guess
if
different,
if,
if
as
a
consumer,
if,
if
you
are
expecting
events
from
you
know
different
systems,
exposing
events
in
you
know
different
ways.
You
know:
Cloud
events
provides
a
way
to
climb
them
so
that
the
consumer
only
needs
to
understand
one.
A
The
common
location
refers
to
a
well-known
key
in
the
payload,
essentially
they're
saying,
if
you're
looking
for
a
timestamp
timestamp
is
going
to
be
this
particular
key
in
the
payload
I
think
that's
what
you're
they
are
referring
to.
That's
how
I
understand
it
and
I
say
it's
additive,
so
there
can
be
other
stuff
that
you,
you
probably
don't
know
about,
but
things
that
you
know
about
and
expect
to
find
there.
They
are
going
to
be
there
at
a
known
place
at
a
known
location.
A
Well,
yeah
I
guess
an
open
format
in
a
way:
I
guess
yeah.
It
doesn't
restrict
things
but
says
what
potentially
can
be
there.
Okay!
Think
of
it
also
as
a
like
it
says:
maybe
it's
there
right
if
it's
mere,
if
it's
there,
then
probably,
then
then
it's
gonna
happen.
A
name
like
that
you
can.
You
can
look
up
the
key.
It's
probably
going
to
be
there,
but
maybe
it's
not
there
as
well.
It's
optional!
A
D
E
No,
it's
not
a
specific
format
like
in
a
protocol
structure
or
something
but
I
think
they
still
specify
what
a
cloud
event.
What
are
the
fields?
The
cloud
event
should
consist
of,
and
some
of
them
you
know,
are
used
to
represent
standard
items
like
you
know
the
data
you
know
some
ID,
some
name
type,
so
it
does
tell
what
fails
and
the
cloud
event
has,
except
that
you
know
they
don't
have
one
format
on
the
wire.
C
And
really
what
we're
trying
to
get
out
of
cloud
events
at
this
point
is
just
like
you
know
some
assurance
that
whatever
we
come
up
with,
we
can,
we
can,
you
know,
represent
those
in
as
Cloud
events
at
some
point
in
the
future,
if
needed,
I.
E
A
E
No,
nothing
I,
think
you
know
it's
more
of
understanding
what
cloud
events
is
used
for
and
understanding
them
better.
So
for
those
anyone
who
is
interested,
you
know
they
can
join
the
messaging
seat
tomorrow,
I
I
plan
to
go
there
and
discuss.
A
E
So
if
you
look
at
the
API
in,
in
our
case,
we
we
say
emit
an
event,
an
event
has
a
name
and
a
bunch
of
attributes,
and
we
also
have
an
issue
open
where
we
are
asking
for
an
attribute
call
event.data,
which
consists
of
the
the
events
payload.
E
So
we
still
will
have
other
attributes
at
the
top
level.
So
we
are
considering
in
a
suggesting
change
to
the
events
API
to
take
one
more
set
of
attributes
that
will
go
at
the
you
know
at
the
a
siblings
driven.data,
whereas
in
in
Cloud
events
each
of
those
items
at
the
top
level
there
they
are
explicitly
defined
in
the
specs.
So
so
they
they.
They
have
it
explicitly
laid
out
in
the
API.
C
I
think
it's
reasonable
if
we
like,
so
we
haven't
gone
in
that
direction.
Yet
have
we
we
haven't
like
specified
that
there's
an
event
data
field
and
then
I
don't
know
what
else
you
would
call
it
event:
attributes
yeah.
E
So
we
did
have
an
issue
open
on.
E
And
we
do
have
some
use
cases
where
you
know
there
will
be
additional
attributes
outside
like,
for
example,
in
the
client
sync.
We
were
talking
about
an
event
priority
export
priority.
We
want
some
events
to
skip.
You
know
the
the
batch
processors
and
get
exported
right
away.
So
if
we
were
to
indicate
such
a
field
in
the
event,
it
will
have
to
be
outside
the
data.
C
Well,
I,
guess
just
you
know,
so,
there's
some
conversations
going
on
about
the
event
data
model,
essentially
so
what
what?
What
Fields
exist
in
the
semantic
conventions
for
events,
how
you
structure
event
data
and,
to
the
extent
that
those
fields
exist,
I
think
that
they
should
manifest
in
the
event
API,
and
there
should
be.
You
know-
good
syntactic
sugar,
essentially
to
to
create
events
with
those
fields
in
mind.
C
But
you
know
I
think
it
could.
We
could
be
getting
ahead
of
ourselves
if
we're
trying
to
shape
the
the
event
API,
based
on
like
hypothetical
changes
to
the
essentially
what's
like
the
event,
data
model
or
the
event
semantic
inventions.
E
And
the
event
semantic
conventions
today
has
only
two
Fields
right:
I
think
only
the
name
and
the
domain.
It
doesn't
talk
about
anything
else
and
in
with
this
issue,
we
want
to
introduce
event.data.
C
Right
so
I
guess
my
recommendation
would
be
to
land
this
PR
or
or
reject
it
one
or
the
other
and
either
as
a
part
of
this
or
in
a
follow-up.
You
know
make
changes
to
the
event
API
such
that.
Like
event,
data
has
special
treatment
and
any
other
like
special
fields
that
are
added.
A
I
agree
with
Jack
here,
so
the
I
think
so
technically
you
can
use
the
logs
API
to
build
your
event
that
matches
the
semantic
conventions
for
events
right.
The
reason
you
have
an
events
API
is
so
that
it's
easier
to
be
with
conformant
event,
the
one
that
actually
has
the
right,
Fields
or
the
right
attributes
and
they
are
defining
the
semantic
conventions.
So
it's
probably
reasonable
to
expect
that
whatever
you
have
defined
in
the
semantic
conventions
for
the
event,
has
some
sort
of
sort
of
counterpart
in
the
events
API
right.
A
So
it's
a
it's
sort
of
a
first
class
citizen
in
the
API
as
well.
Just
makes
it
easier
to
do
to
do
the
right
thing
to
to
shape
the
event
correctly.
Otherwise
that
that
to
me
is
the
whole
purpose
of
that
thing:
right
otherwise,
I
just
I'll
just
use
the
the
generic
raw
logging
API.
Why
would
I
need
a
different
API.
E
Sorry,
are
you
suggesting
that
we
raise
a
PR
to
introduce
event.data
into
the
event
semantic.
A
C
C
I
I,
you
know
if
you
want
to
modify
this
PR
to
have
corresponding
changes
in
the
event
API,
and
you
know,
land
those
together,
I
think
that
would
make
sense
I.
You
know
I
think
you
could
also
land
this
PR
first
and
then
try
to
make
an
attempt
to
change
to
the
event
API.
If
you
want
to
do
it
in
in
sequential
steps.
E
C
If,
by
this
direction
you
mean
having
Fields
added
to
the
semantic
conventions
and
having
you
know
corresponding,
you
know,
Setters
or
you
know,
a
surface
area
in
the
event
API
then
yes,
I,
agree.
Okay,.
A
E
Okay,
all
right
so
as
a
follow-on,
if
all
the
payload
of
the
event
is
in
the
event.data,
so
we
yesterday
me
and
a
few
others
were
going
through
a
few
examples
of
events,
and
there
is
an
event
of
type
exception
today.
E
It
already
defines
that
its
attributes
should
be
exception:
Dot
name
exception,
dot,
stack,
Trace,
all
there
are
exception
prefixes
and
for
the
nested
attributes
we
were
thinking
of
not
going
not
defining
in
the
semantic
conventions,
all
the
keys
inside
the
nested
attributes
we
for
not
thinking
of
putting
them
in
these
semantic
conventions,
so
they
will
not
have
namespace
prefixes.
E
If
we
go
by
that,
then
we
were
wondering
if
we
could
even
modify
the
exception
events.
Only
in
the
case
of
log
events
span,
events
I,
don't
know
yet,
but
at
least
in
the
log
events
case,
could
we
put
the
exception
attributes
inside
the
event.data,
in
which
case
they
will?
They
will
not
need
an
exception.
Prefix
name
specifics.
A
E
In
some
ways,
it's
okay,
because
it
also
aligns
with
Cloud
events
where
the
top
level
attributes
are
control,
attributes
and
the
payload
is
in
in
one
attribute.
A
D
G
I
was
just
basically
going
to
ask
the
same
thing:
I
can't
remember,
I
know
we
talked
about
this
before,
but
why
event
data
is
needed.
You
can't
use
that
attributes.
E
I
think
nav
was
asking
for
it.
I
think
he
just
left
for
another
meeting.
So
we
could
continue
this
discussion.
You
know
next
week,
but
I
think
it's.
E
G
E
Now
we're
not
talking
about
mapping
Cloud
events
to
open
Telemetry
events
is
in
in
when
we
are
constructing
events
in
open
Telemetry
using
open,
telemetry
apis.
H
So
so
the
the
reason
like,
based
on
what
I
remember,
is
like
well
like
what
Santosh
said.
One
is
to
separate
the
payload
from
like
other
attributes
that
could
be
added
on
on
the
log
record
itself
and
also
there's
been
there's
been.
A
a
few
people
is
like
there
was
a
desire
to
basically
have
ability
to
verify
it
like
or
to
all.
H
Word
who
validates
that
the
payload
is
is
correct
so
like,
if
you,
if
you
mixed
the
the
event
specific
attributes
with
like
user
attributes,
you
couldn't
do
that.
E
Could
Point
only
to
the
the
validation
would
be
only
against
the
data
and
the
payload
right.
A
E
Maybe
maybe
could
you
I'll
put
some
of
these
comments
in
in
that
pull
request?
Could
you
also
yeah.