►
From YouTube: 2022-06-22 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
B
A
So
I
put
two
things
on
the
agenda
for
today:
does
anyone
have
any
other
topics
to
talk
about
today?.
A
A
So
the
first,
the
first
thing
I
would
just
wanted
to
run
by
this
group
and
I'm
not
sure
if
we
can
answer
this-
maybe
maybe
I
should
just
ask
ted,
but
we
have
we
have
that
event.
C
Again,
a
couple
of
mobile
developers
in
this
round.
So
if
there
are
any
mobile
related
questions,
topics
to
discuss,
I
have
again
android
ios
and
remote
nick
also
joined
again,
so
there's
also
hybrid
knowledge
there.
A
The
through
these
the
topics
we
have
on
the
list-
and
maybe
we
can,
if
you
have
time
to
talk
about
the
app
crash
we
touched
based
on
it
a
little
bit
yesterday,
but
we
can
continue
with
so
so
a
couple
things
that
I
wanted
to
talk
about.
First,
we
have
that
events,
api
otep
in
progress
and,
at
the
same
time
we're
working
on
the
semantic
conventions,
and
I
was
wondering
if
we
could
actually
start
proposing
the
semantic
conventions
or
do
we
need
to
wait
for
that
otep
to
be
accepted.
A
I
was
I
was
thinking
like
we
could.
First,
first
start
by.
You
know
open
opening,
an
issue
pr
for
the
event
namespace
and
in
my
domain
event
name
and
get
some.
You
know
to
start
the
discussion
with
the
wider
community
on
on
those,
but
it's
it's
very
much
tied
to
the
api.
So
I
was
just
wondering
like
what
other
others
think.
A
You
know
there
will
be
events
as
there
will
be
semantic
conventions
proposed
for
individual
events
that
belong
to
a
certain
domain,
whereas,
like
the
semantic
conventions
right
now
are
more
just
the
name
space
and
then
they're
composable,
the
name
spaces
are
composable,
so
it's
a
little
bit
different.
The
way
the
semantic
dimensions
are
are
going
to
be
structured.
E
That
might
be
worth
with
an
otep
if
it's
going
to
be
a
pile
of
related
conventions
that
all
follow
the
same
pattern
that
might
be
worthwhile
to
define
because
you're
saying
anyone
else
who
comes
along
later,
who
wants
to
define
further
events
needs
to
follow
this
pattern,
yeah
that
that
might
be
worthwhile.
It
doesn't
slow
things
down
too
much.
B
Yeah,
I
think,
that's
probably
if
we
have
a
convention
saying
this
is
the
shape
of
the
event.
I
think
that
that's
where
we
definitely
start
saying
we're
going
to
have
a
domain,
the
name
potentially
a
type
data
and
custom
data
somewhere,
and
then
we
come
along
later
and
say,
and
this
is
what
for
this
domain.
These
are
the
events
and
then
this
is
what
they
look
like.
D
There
are
a
couple
other
things
that
we
need
to
discuss
and
agree
on.
I
think
one
is
you
know
the
attributes
supporting
any
value.
D
I
think
that's
a
prerequisite
for
what
we
just
said,
and
the
second
prerequisite
is,
I
think
we
we
need
to
between
ourselves.
I
think
we
need
to
come
to
an
understanding
of
what
are
some
sample
domains
that
we
wish
to
have
the
browser
and
mobile
a
couple
we
can
think
of,
but
we
want
to
use
you
know
those
as
the
names
and
are
there
any
other
domains.
So
once
we
have
some
potential
values,
then
we
can
include
that
in
that
proposal.
B
Yeah,
but
one
thing
that
stefan
came
up
with
yesterday
is
rather
than
saying,
browser
and
mobile,
and
you
came
up
with
defining
it
as
where
it
is
in
the
process,
so
we
could
have
a
life
cycle
and
then
any
common
events
that
fall
in
into
there.
That
could
be
shared
across
the
different
platforms
we
can
chuck
into
that
domain,
but
there
will
be
still
be
domains
which
are
specific
to
like
browser.
Like
the
timing.
B
Events
that
martin's
been
working
on,
I
think
we're
gonna
have
to
say
that's
just
browser
timing
and
then
the
app
crash
that
you
mentioned
centos
might
fall
into
a
a
mobile
or
a
some
other
domain,
or
we
just
say
these
are
all
hotel,
client
and
then
we
make
the
event
name
unique.
D
So
this
part
is
slightly
confusing,
so
those
two
examples
that
you
mentioned
they
both
are
actually
you
know
not
necessarily
belong
to
those
domains
and-
and
it
is
fine-
I
guess,
the
performance,
navigation
timing,
information.
D
I
think
we
should
discuss.
I
think
that
is
the
next
topic
I
feel
like
you
know
that
might
be
applicable
even
for
on
the
api
calls
that
occur
outside
the
browser
and
the
mobile
app
like.
Let's
say
the
back
end,
my
microservice
calling
another
microservice
that
might
also
have
similar
information,
so
it
could
also
have
the
same
event.
So
there
can
be
two
events.
D
You
know
which
are
literally
the
same,
but
you
know
might
be
sent.
You
know
in
two
different
domains
for
these
two
cases,
so
I
I
I.
B
Think
is
that
fine
yeah
I
I
do
want
to
try
and
avoid
that.
But
we've
been
very
because
we're
effectively
following
the
w3
3c
spec
for
timing,
and
I
think
we
got
feedback
from
stefan
yesterday-
that
they're
probably
unlikely
to
have
a
lot
of
crossover,
but
if
they
can,
then
let's
try,
but
we
need
to
go
and
define
all
the
events,
which
is
what
ted
suggested
earlier
on.
We
go
and
say
browser
mobile
whatever,
and
then
we
try
and
see
we'll
see
what
canon
can't
be
merged
and
go
from
there.
B
But
I
agree
I'm
just
dropping
I.
I
do
have
a
a
pr
out
for
a
spec
change
about
the
attributes
supporting
any.
B
I
tried
to
be
a
little
bit,
taking
into
account
all
the
all
the
issues,
but
I'm
sure
it's
still
gonna
probably
get
pushed
and
and
it's
gonna
be
fun
to
try
and
get
merged.
But
really
all
I've
done
is
just
define
in
the
spec.
What
protobuf
already
does
and
what
javascript
already
does.
So
it's
it's
not
like.
I'm
not
proposing
any
changes
here,
I'm
just
documenting
what
can
already
happen
so
but
we'll
see
what
happens.
D
Okay,
on
the
first
topic,
I'm
not
entirely
clear
what
you're
proposing
that
is.
Let's
say
an
application
crash
right,
it's
quite
possible,
for
you
know
any
applications
across
not
just
browser
app
or
the
mobile
app.
Let's
say
your
your
micro
service,
you
know,
would
be
crashing
so.
D
B
One
option
I
came
up
there
yesterday,
there's
two
different
types
of
crashes:
there's
there's
handle
crashes
and
completely
terminal
fatal
crashes.
So
one
possible
proposal
is
we
say:
okay,
we
have
a
generic
exception
which
pretty
much
already
exists.
We
just
kind
of
like
leverage
that
and
say
hey
something.
You
know
something
bad
happened
and
then
for
the
level
of
detail
which,
as
you've,
got
in
your
in
the
comment
for
the
thing
is
potentially
like
a
file
upload.
B
We
have
effectively
a
separate
event.
So
in
the
case
of
a
fatal,
oh
crap,
the
thing
is
dying.
It
would
actually
try
and
spit
out
two
events,
one
to
let
the
user
know
that
something
bad
happened
and
then
the
second
would
be
what
the
more
detail
to
follow
up,
because
it's
more
like
a
log
because,
depending
on
the
platform-
and
it's
definitely
co
correct
me
if
I'm
wrong
here,
it's
it's
going
to
depend
on
the
content.
B
D
So
so
what
what
I
I
sorry,
I
missed
what
what
is
this
conclusion?
Like?
Are
you
suggesting
we
have
one
common
domain
here,
these
existing
separate
domains
for.
B
So
the
proposal
that
I
had
yesterday
was
a
common
domain
for
the
fact
that
an
error
happened
I.e
an
exception
as
a
signal
to
say
that
you
know
something
happened
and
then
it
would
be
a
specific
domain
for
the
app
crash
details
potentially
or
we
can
just
say
it's
still-
the
otel
client
domain.
But
it's
a
specific
event
saying
android
app
crash,
ios
app
crash
or
something
like
that.
But
that
was
we're
still
trying
to
figure
out
what
that
should
be.
B
Well,
there's:
if
the
app
crashes,
we
can
either
say:
okay,
let's
try
and
get
all
this
and
put
it
into
the
exception
so
that
the
back
end
can
handle
it
all
or
my
proposal
was
we.
We
say:
okay,
let's
leverage
the
existing
exceptions
or
anything.
That's
any
back-end
system,
that's
listening
to
exceptions.
Would
it
would
all
of
a
sudden
get
an
event
saying
app,
crashed
and
then
for
the
level
of
detail.
That
would
go
to
a
different
event.
B
So
this
is
equivalent
like
in
windows,
we'll
get
an
event
saying
you
know
thing
terminated
and
then
effectively
you'll
get
the
watson
dump
later.
It's
not
sent
out
at
the
same
point
in
time.
D
B
D
C
D
C
D
C
D
Okay,
so
for
these
two
events
I
I
would
still
think
that
use
you
know
one
common
domain
and
that
domain
would
be
different
in
each
of
the
you
know,
use
cases
so
the
mobile
will
send
use
one
domain.
The
backend
will
use
one
domain
and
is
there
a
harm
to
do
that.
B
I
wouldn't
think
so.
I,
like
my
preference,
would
be
that
we
say
the
domain
would
be
like
otil
client
and
then
we
make
the
event
names
unique
for
the
type
of
event
that
we're
sending
I'm
going
to
caveat
that
with
and
until
we
understand
what
all
the
types
of
events
are
and
what
we
can
and
can't
merge.
B
B
I
don't
think
we
have
enough
information
to
make
that
call
in
terms
of
do.
We
need
to
have
a
specific
domain,
or
do
we
want
to
yeah
like
what
what
events
have
we
got?
Let's
say
so.
D
Just
to
remind
the
let's
revisit
why
the
domain
was
added
right.
I
think
the
domain
was
added.
Only
purely
for
the
purpose
of
you
know.
Avoiding
conflicts
surprises
surprise.
I
mean
some
confliction
or
that
could
surprise
us,
so
you
use
some
event
name
and
then,
two
years
later,
somebody
independently
in
a
completely
different
context
would
use
the
same
event.
D
So
to
avoid
that,
and
only
to
avoid
that
it
was
recommended
that
we
we
publish
ahead
of
time,
what
are
some
possible
domains
that
we
agree
on
and
then
people
are
free
to
use.
D
D
What
the
hotel,
I
think,
hotel
client,
could
be
misleading
because
you,
you
just
mean
a
client
right.
Not
an
hotel
client
typically
would
mean
an
agent
right
or
tlp
client.
B
Yeah,
I
think
we
look
like
there
is
the
the
profiling
guys
and
they
are
probably
going
to
end
up
creating
a
different
signal
because
they're
talking
about
the
factory
file
uploads,
not
individual
profiling
events,
because
I
went
to
their
meeting
last
week,
but
we
may
have
like
okay,
we
like
we
could
easily
call
it
like
hotel
rum,
but
I
I
don't
like
calling
it
rum.
I
I
think
it's
it's
having
his
client
is
more
generic,
but
there's
a
lot
of
overloaded
terms
in
open
telemetry.
B
D
B
D
But
even
I
have
a
concern
even
with
client
or
ram,
because
I
I
I
what
about
further
separating
mobile
and
browser?
Do
you
want
to
see
a
need
for
that.
B
Well,
that's
right,
I
think
the
event
name
so
and
then,
for
example,
if
we
said
the
domain
is
just
unique
to
this,
and
I
I
keep
saying
oto
on
the
front,
because
I
think
we
want
to
have
hotel
as
a
name
space
for
so
that
people
can
use
this
for
their
own
custom
events.
We
say,
like
your
browser.timing,
I
think
that's
potentially
you
know
a
possibility
because
we're
following
w3c-
or
maybe
we
just
say,
w3c
timing,
yeah,
that's,
I
guess
another
one
speaking
out
loud,
so
yeah.
B
I
I
think
the
event
names
themselves
are
going
to
be
unique.
I
would
like
to
try
and
have
a
common
set
of
as
many
common
events
as
we
can
that
are
not
specific
to
any
particular
type
of
client,
but
we
are
going
to
have
to
have
some.
D
So,
aside,
stuff,
what
what
is,
what
is
it
that
you
are
referring
to
as
w3c.
B
The
w
the
web
three
prince
audio
so
that
effectively
they've
defined
the
so
the
effect
yeah.
The
performance,
navigation
timing.
D
Yeah,
but
in
this
case
all
the
performance,
you
know,
timing
entries,
I
thought
they
they,
they
are
not
part
of
the.
I
see.
B
So
pretty
much
all
these
fields
are
optional,
because
not
every
browser
gives
them
to
you
and,
depending
on
the
the
time
frame,
you
may
not
have
them
either.
So
we're
just
saying
the
shape
of
the
browser.
Timing
event
is
in
fact,
where
you
can
have
a
type
that
I
think
we
talked
about
a
couple
weeks
ago.
Look
like
this.
D
We
could,
you
know,
think
about
this
and
get
more.
We
could
yeah
go
with
what
you
have
to
listen
and
then
come
back.
A
So
one
thing
I
want
to
point
out
is
so
we
have
two
options
we
can.
We
can
either
make
that
domain
specific
to
the
type
of
instrumentation
like
browser
or
mobile,
or
we
can
make
it
generic
like
you're,
proposing
nav,
and
then
we
can
make
that
those
distinctions
in
the
event
names
the
one,
the
one
advantage
of
maybe
having
them
the
domains.
A
More
specific
is
that
you
could
have
different
different
sigs
or
different
interest
interest
groups
that
are,
you
know,
focusing
only
on
defining
the
events
in
their
domain
without
having
to
you
know,
synchronize
with
other
interest
groups
like
we
could
focus
like.
We
have
a
focus
browser
group
that
just
works
on
events
for
browser,
and
we
can
have
mobile
group
for
the
work
zone.
Events
for
mobile-
I
also
see
like
the
you
know.
The
the
having
having
common
attributes
is
definitely
has
also
some
advantages
too.
D
A
The
the
other
thing
that
I
want
to
point
out
is
if
we
we
should
make
it
clear
that
if,
if
the
domain
is
more
broad
like
client,
then
the
domain
cannot
be
used
for
routing
events
in
in
in
the
back
ends.
D
You
know
one
for
each
domain
and
then
that
kind
of
is
odd.
So
you
will.
D
You
don't
know
right.
I
think
that
so
for
for
this
event
that
we
were
discussing
right
now,
we
are
talking
about
one
is
the
client
and
another?
Is
the
hotel,
client
or
wpc.
So
there
might
be
more.
A
The
way
I
understood
it
is
that
it
would
be,
it
would
still
be
the
like.
The
w3c
would
be
the
event
name,
not
the
domain
right.
D
So
the
prefix
mobile
or
browser
for
on
the
event
name.
I
thought
you
know
the
the
having
a
domain
would,
you
know,
will
make
that
prefix.
You
know
not
required
anymore,
so.
D
The
domain
actually
takes
care
of
the
prefix
part
on
the
event,
so
that
that's
one
advantage.
So
so
you
don't
need
to
prefix
everything.
So
that
way,
you
could
reuse
that
event
name
across
you
know
multiple
domains
and
therefore
could
have
the
same
code.
Let's
say,
for
example,
your
node.js
right
now,
your
backend
apps
could
use
the
same
code
instrumentation
code
to
generate
an
app
cache
and
and
and
just
depending
on
the
context.
You
know,
they'll
supply.
B
That
is
a
different
way
of
looking
at
where
we
actually
define
the
event
and
say
this
event
can
appear
in
these
domains.
So
that's
another
possibility
yeah,
but
yeah,
because
the
api
is
the
case.
You
have
to
fix
the
logo
with
the
domain.
I
think
yeah
we
want.
We
want
an
application
to
effectively
request
an
event
emitter
once
rather
than
saying.
Well,
this
is
the
type
of
event
I
want
to
admit
so
yeah
having
a
common
domain
for
the
lifetime
of
the
app
so
yeah
it
comes
down
to
yeah.
E
B
But
we're
defining,
I
I
would
think
within
the
domain,
because
the
event
api
can
be
events
that
the
voter
limit
or
third
parties
can
emit.
So.
E
Right
but
like
I
think,
we're
trying
to
use
that
domain
like
the
hotel
prefix
would
be
for
like
describing
admitting
the
configuration
information
of
the
hotel,
client
or
api,
or
something
like
that.
Does
that
make
sense.
E
A
D
B
D
Instead,
instead,
I
think
you
know
even
in
the
existing
rota.
You
know
daniel
pointed
out
that
I
have
a
lot
of
content.
That
is,
that
is
not
rotep
material,
but
you
know
it
should
be
respect
pr.
D
So
I
think
we
could
go
ahead.
You
know,
do
the
same
discussion.
E
E
E
Then,
when
you
go
in
and
make
prs
for
like
add
this
semantic
convention
at
this
semantic
convention
at
this
semantic
convention
and
they're
all
adhering
to
this
structure,
but
like
that
structure
hasn't
been
defined
anywhere,
you
might
end
up
with,
with
some
confusion
happening
across
a
bunch
of
pr's,
so
that
that's
that's
my
thought
process
for
why
getting
that
into
an
otep
might
might
be
helpful,
because
it's
a
place
where
you
can
get
agreement
that
we
should
write
all
of
these
things
down
in
this
manner
yeah.
E
But
I
wouldn't
necessarily
hold
up
making
those
prs
for
those
individual
semantic
conventions.
So
I
might
also
add
that,
like
maybe
just
like
just
cover
your
your
bases
by
by
adding
that
otp.
E
A
D
Yeah,
I
I
want
to
you,
know,
spend
few
minutes
discussing.
You
know
the
contents
of
the
audit.
You
know
I
I
have
a
feeling
that
it's
going
to
be
redundant
as
in
the
primary
point
was
to
you
know,
have
an
event
name
in
the
log
record
and
anything
on
top
of
it
is
all
optional
right.
So
when
you
say
shape
of
an
event,
you
know
what?
What
more
do
you
want
standardized?
D
You
know
having
a
data
attribute.
I
think
we
have
another
proposal
to
make
that
attributes
you
know
accept
anything.
So
would
would
that
not
be
sufficient.
A
Well,
I
think
my
my
initial
reason
for
opening
this
otep
was
because
we
are
introducing
the
concept
of
domains
and
semantic
conventions
being
organized
around
the
concept
of
domains,
as
opposed
to
the
concept
of
you
know
the
namespaces,
and
so
you
know,
if
you
define
cement
conventions
for
like
a
browser
event.
D
Okay,
I
I
I
don't
know
ted.
What
do
you
think
about
this?
But
you
know
if
it's
maybe
a
few
weeks
like
two
or
three
weeks
of
discussion,
then
we
could
fill
that
to
the
current
order,
because
if
it
was
a
new
depth,
you
know
it
could
take
more
time.
E
E
E
D
Okay,
maybe
let's
have
one
discussion
in
the
lobster
as
well.
Martin,
let's
see
what
folks
there
think.
If
it's,
I
think,
I
think
we
need
to
have
a
general
understanding
of
what
a
domain
is
and
how
it
will
be
used
and
and
not
necessarily
what
potential
values
a
domain
can
take.
You
know
which
could
you
know,
be
a
bigger
discussion.
So
if
we
agree
on
you
know
r
or
if
we
are
successful
in
you,
know
defining
what
a
domain
is
very
clearly
in
this
row.
E
I
would
agree
with
that.
You
you're
just
my
suggestion,
for
this
is
just
so
that
when
you
start
producing
lots
of
spec
pr's
for
each
different
domain,
that
you've
just
got
that
the
framework
that
you
just
described
in
place.
E
D
Okay,
and
and
just
to
be,
you
know,
super
clear
and
marketing.
I
think
the
the
only
debate
we
need
to
have
is
really
the
values
for
the
event
domain
right
and
not
on
the
understanding
of
the
domain
itself.
B
D
Yeah,
so
the
first
two
are
are
baked
into
the
api
yeah,
the
domain
and
the
element.
So
so
that
is
settled
the
event
data
is
slightly
controversial
because
our
apis,
you
pass
the
data
in
the
form
of
attributes
and
and
the
api
itself
you
know.
Doesn't
you
know
directly
support
what
you
are
talking
about
right,
what
you
passing
as
attributes.
You
know
it
could
be
anything,
and
if
you
are
saying
that
data
itself,
you
know
has
to
have
another.
You
know
one
specific
attribute.
B
B
So
when
we
come
to
define
and
say
this
event
has
this
that's
a
case
of
where?
Okay,
when
you
call
the
api,
you
get
your
logo
for
that
domain
and
then
you
say,
emit
this
event
name
and
then
you
give
it
those
attributes.
So
I
think
that's,
that's
all
that's
defining,
but
if
we've
got
the
shape
of
the
event
saying
when
you
emit
an
event,
it
will
have
domain
name,
potentially
type,
potentially
custom
data
and
data,
as
as
the
main
elements.
B
D
So
wouldn't
that
be
sufficient?
You
know,
you
know
semantic
conventions
here
where
you
know
in
a
table
of
all
the
event
attributes
you
say
even
named
and
then
even
dot
data,
and
then
you
know
make
it
optional
and
there
you
know
you
give
good
examples
of
what
an
even
data
would
implode.
B
Yeah
it's
like
do
we
define
it
in
the
o
chap
so
that
when
we
come
to
do
the
specification,
it
just
leverages
that
I
don't
know
it's
probably
about
to
tend
to
make
a
call
in
terms
of
where
we
define
that
level
of.
D
Yeah,
and
also
just
just
sorry,
I'm
dragging
this
a
little
longer,
but
I
I
still
feel
like
whether
or
not
people
used
you
know
data
attribute
what
implications
does
it
have
like
you
know
I,
you
know
we
introduced
the
name
and
the
domain
for
specific
reasons
that
we
need
name
to
distinguish.
You
know
between
events
and
log
and
logs
right,
so
the
event
name
has
a
purpose.
The
domain
has
a
purpose
to
avoid
the
conflicts
on
the
even
names
now
the
data.
You
know
whether
people
follow
it
or
not.
D
B
B
B
Well,
I'm
going
to
have
my
own
custom
domain
with
my
own
custom
event,
and
I
can
do
whatever
I
like
and
then
their
own
custom
back
end
does
with
that,
whatever
they
like,
but
that's
not
what
we're
defining
here
we're
defining
what
what
we
are.
We
are
recommending
as
the
hotel
events.
A
And
I
just
just
have,
I
think,
the
the
the
reason
we
were
proposing
event
data
was
because
for
browser
we
want
to
minimize
the
the
size
of
the
payload.
B
It's
not
just
that
it's
like
even
for
our
react
users,
which,
I
guess
is
the
browser,
that's
the
javascript,
our
node
sdk,
which
is
separate.
It's
not
owned
by
me.
By
hector.
B
We
have
the
ability
to
pass
in
multi-level
nested
objects
because
it
still
goes
the
same.
Back-End
and
the
back-end
supports.
You
know
the
user
passing
their
own
custom
events.
So,
while
storing
everything
in
data
does
help,
in
fact,
it's
almost
mandatory
for
a
browser
because
you
don't
want
to
like,
have
it
flat.
B
It's
that's,
not
the
only
reason.
It's
not
just
a
browser
even
for
for
a
mobile
device.
If
you're
on
a
mobile
device
on
a
well
2g
feed.
You
don't
exist
anymore
here
in
the
us,
if
you're
in
india
or
australia
or
somewhere
else,
where
you
have
a
low
bandwidth
environment,
you
want
to
minimize
the
amount
of
data
you're
trying
to
send.
A
B
The
payload
yeah
yeah,
both
in
terms
of
like
the
actual
bytes
going
down
the
wire,
as
well
as
creating
said,
payload
and
and
holding
it
in
memory.
D
Okay,
yeah,
I
I'll
alert
you.
I
think
I
I
agree
on
on
the
concept.
I
I
just
don't
I'm
not
sure
whether
it
needs
just
a
semantic
convention
might
be
sufficient,
but
yeah.
D
A
Okay,
we
have,
we
have
about
10
minutes
left
ted.
Do
you
want
to
quickly
talk
about
your
old
tap
before
I
get
into
yeah.
E
Yeah
totally
so
I've
created
a
otep
for
what
I'm
calling
ephemeral
resource
attributes.
E
This
is
the
place
where,
hopefully,
we
can
store
things
like
session
id
and
user
information,
language
preference
time
zone
stuff,
like
that,
I
don't
think
anything
in
it
should
be
surprising
to
anyone
who's
been
following
the
working
group,
but
just
to
go
over
it
briefly.
E
The
basic
shift
here
is
that
today,
in
open
telemetry,
a
resource
is
an
immutable
object
and
sdk
takes
this
resource
in
when
it's
initialized
and
there's
no
way
to
update
it
after
the
sdk
has
been
initialized.
E
The
reason
for
that
is,
existing
resources
that
have
been
defined
are
seen
as
permanent
resources,
so
they're
things
defining
things
like
the
process
id
the
device
type,
the
kubernetes
cluster
stuff.
That
is
going
to
be
an
invariant
across
the
lifetime
of
the
process
and
there's
because
some
of
these
those
resources
can
take
a
bit
of
time
to
get.
For
example,
you
need
to
make
an
api
call
to
fetch
some
information
from
aws
or
something
before
you
can
create
a
resource.
E
They
didn't
want
resources
being
updatable,
because
that
would
lead
to
this
bad
pattern.
Where
end
users
would
start
their
process,
start
emitting
data
and
then
later
attach
some
critical
resource
that
needed
to
be
on
all
of
the
data,
including
the
data
they'd
already
admitted.
E
So
this
proposal
tries
to
kind
of
bridge
those
existing
requirements
for
what
I'm
now
calling
permanent
resources
with
the
new
requirements
that
this
group
has
for
resources
that
are
going
to
change,
because
client
apps
have
a
different
lifecycle
from
server
apps,
where
they
may
go
idle
or
go
to
sleep
and
re-awake,
in
which
case
some
of
the
resource
attributes
associated
with
them
might
change.
So
the
way
we
do,
that
is
by
adding
a
new
concept
called
a
resource
provider.
E
This
resource
provider
is
handed
around
to
the
sdk
and
anytime.
The
sdk
creates
a
new
signal
like
a
span
or
an
event
or
metric
the
resource,
the
resource.
It
asks
this
resource
provider
to
give
it
the
current
resource.
E
E
It
can
be
atomically
updated
because
it's
a
reference,
so
this
should
preserve
the
runtime
characteristics
of
resources
and
to
help
with
ensuring
that
permanent
resources
don't
get
abused
by
this
new
feature.
E
I've
added
proposed
a
method
on
the
on
the
resource
provider
called
freeze
or
freeze
permanent,
and
the
sdk
basically
calls
that
when,
when
it's
initialized
and
that
allows
a
resource
provider
implementation
to
do
something
like
take
a
validator
of
some
kind
and
then
after
freeze
permanent
is
run,
it
can
run
that
validator
on
any
call
to
set
attribute
and
refuse
to
update
it.
E
If
you
know
the
the
attribute
key
matches
its
list
of
permanent
attributes,
I
wrote
it
that
way,
also
so
that
potentially,
if
there's
some
kind
of
overhead
associated
with,
say,
storing
that
giant
list
of
all
the
permanent
resources
or
something
like
that,
which
is
the
thing
you
know
browsers,
might
not
want
to
do
it's
not
a
requirement
in
this
otep
that
that
validator
be
run.
It's
just
ensuring
that
there's
a
mechanism
for
for
doing
so.
E
So
so
that's
that's
the
way
the
zotep's
shaped.
I
think
it
covers
every
way
that
we
promised
backwards
compatibility
with
resource
except
one,
which
we
never
explicitly
wrote
down
as
a
requirement.
E
E
I
have
not
seen
any
evidence
that
anyone
is
doing
that
I
have
been
asking
around,
but
that's
just
the
one
thing
I
want
to
flag
here,
which
is
if
it
turns
out
that
is
common,
and
we
just
didn't
know
about
it.
We'll
have
to
we'll
have
to
deal
with
that.
A
A
E
Yeah
we're
we're
sticklers
for
backwards,
compatibility
and
open
telemetry.
We
try
to.
We
try
to
take
an
approach
to
backwards
compatibility.
E
That
is,
if
we
told
you
something,
then
we
have
to
stick
by
it,
not
if,
if
we
can't
think
of
some
way,
this
might
break
someone,
then
it's
okay
right,
because
it
turns
out
the
internet's
a
big
place
and
there
are
plenty
of
ways
you
might
not
think
of
a
way
that
how
you
change
something
broke
people's
requirements,
and
so
this
is
just
one
place
where
that,
when
I
made
this
proposal
to
the
spec,
the
broader
spec
community
in
the
past,
the
first
piece
of
feedback
we
get
always
is,
but
resources
aren't
immutable.
E
We
said
that
they
don't
they're
an
invariant
and
now
you're
making
them
very,
and
so
that
seems
like
it's
breaking
backwards
compatibility.
So
I
think
that
will
probably
more
than
anything
else
in
this
otep.
That's
going
to
be
the
sticking
point
that
the
discussion
is
going
to
center
on,
which
is
why
I've
included
this
concept
of
a
permanent
resource
versus
an
ephemeral
resource
and
a
way
to
to
verify
it
that,
but
the
only
thing,
the
the
only
part
of
that.
E
The
only
thing
that
that
mechanism
wouldn't
cover
would
be
if
someone
downstream
had
some
expectation
that
they
had
somehow
baked
into
their
code,
and
I
don't
think,
that's
a
requirement
we
ever
laid
out
for
for
resource.
But
if,
if
there
are
vendors
walking
around
today,
who
who
did
take?
E
E
I
I
personally
think
it's
fine
to
go
to
we're
not
talking
about
end
users
here
we're
talking
about
people
who
maintain
an
analysis
tool
and
that's
a
much
smaller
group.
So
I
think
it
is
okay
to
maybe
go
to
them
and
be
like
yo
change.
E
Change
your
dumb
hashing
algorithm
to
not
be
just
blindly
smashing
all
of
these
arbitrary
attributes
together.
But
you
know
it's
a
conversation.
We'd
have
to
have
anyways,
so
I
I'm
I'm
digging
into
that
by
the
way
I'm
like
explaining
all
this
to
this
group,
because
I
just
predict
that's
going
to
be
where
the
conversation's
gonna
have
some
some
nuance
other
than
that.
I
don't
think
there's
anything
in
this
otep,
that's
weird!
E
It's
actually
really!
I'm
actually
really
happy
with
how
narrow
a
change
it
is
due
to
the
fact
that
our
open
telemetry's
export
pipelines
already
expect
that
they
might
be
getting
data
in
with
different
resources
attached
to
them,
because
they
might
have
multiple
sdks
feeding
into
the
same
export
pipeline.
So
they
already
sort
the
data
that
they're
batching
out
by
by
resource
set.
E
So
there's
actually
nothing
that
needs
to
change
downstream.
All
that
needs
to
change
is
that
trace
providers
and
metrics
providers,
like
those
sdk
components,
take
in
a
resource
provider
now,
as
as
a
initialization
parameter,
and
that's
also
backwards
compatible
with
them
taking
in
the
old
resource
parameter.
So
so
it
seems
very
clean,
except
for
this
meta
discussion
about
what
did
we
actually
promise
people?
So
hopefully
this
goes
through,
but
that's
that's
gonna
be
the
one
thing,
and
I
am
I'm
going
on
leave
for
three
months,
but
I
will
be
so.
E
I
won't
be
I'm
trying
not
to
be
available
for
a
lot
of
meetings,
but
I
will
be
monitoring
this
otep
and
trying
to
shepherd
it
over
the
over
the
finish
line.
A
There
was
one
more
topic
that
I
wanted
to
talk
about,
and
I
thought
it
was
gonna
be
the
main
topic
today,
so
it's
gonna
have
to
be
postponed
until
next
week,
but
I
wanted
to
just
people
to
think
about
kind
of
a
guideline
of
when
we
use
spans
and
when
we
use
events-
and
I
think
it's
now
that
we're
getting
into
the
specifics
of
the
events,
I
think
it's
going
to
come
up
I'll
have
different
opinions,
but
I
started
by
looking
at
the
navigation
timing
and
resource
timing.
A
A
E
My
one
request
is
just
just
make
sure
event:
handlers
are
all
defined
as
spans
right.
I
don't
know
about
the
events
themselves,
but
to
me
that's
like
the
nuance.
You
have
an
event
that
occurs
and
there's
also
a
then
an
event
handler.
That's
triggered
off
of
that
and
the
event
handler
definitely
needs
to
be
a
span
with
its
attributes
like
described
in
the
in
the
spec.
B
E
The
the
you
don't
think,
you're
saying
you
don't
want
to
automatically
generate
spans
for
event,
handlers
because
it'd
be
like
too
heavyweight
or
something.
No,
it's
just
not
necessary.
In
all
cases
I
mean
like
I
guess,
if
that
event
handler
is,
is
doing
work
you
want
it,
you
want
it
as
a
span.
E
E
B
E
Yeah,
it's
true:
if
you
would
you,
you
wouldn't
want
to
generate
a
bunch
of
noise,
but
but
if
someone
has
attached
something
to
toggle
right,
like
toggle
means,
go
quickly,
fetch
some
json
to
populate
a
something
rather.
E
You
know
like
meaningful
work
and
event
handler
like
how
do
you
name
that
event
handler
span
like
what
attributes
do
you
put
on
that
thing?
How
are
you
going
to
make
it
easy
for
end
users
to
to
do
that
correctly?.
E
Yes,
yes,
if
I
mean
I
think,
as
an
application
developer,
you
know
that
you're
you're
doing
this.
It
would
be
way
more
convenient
and
consistent
if
a
framework
did
it
for
them,
but
then
that
framework's
gonna
automatically
do
it
everywhere.
E
So
a
middle
ground
would
be
something
like
like
a
helper
function.
That
was
like
start
event
handler
span
and
you
hand
it
like
the
like
event
handler
properties
or
something
so
that
you
could
automatically
format
it
for
people.
I
don't
know
yeah
the
noise
is
a
problem,
but
but
but
I
think
that's
just
the.
E
I
think
we
should
still
define
what
those
event
handler
spans
look
like
and
make
it
clear
that
if
you're
gonna
do
any
amount
of
work
in
an
event
handler
you
should
there
should
be
some
consistent
way
to
define
that
yeah
find
that
so
that
back
ends
can
know,
can
like
they're
going
to
want
to
use
that
when
they're
they're
doing
an
analysis
of
these
things
right
depends
on
the
application
yeah.
E
The
event
handler
is
showing
like
this
is
the
user's
experience,
latency
and
oh
god,
that
that
exceeded
some
threshold
that
we
don't
like
is
too
slow,
so
they're
irritated.
Why
is
it
too
slow?
What
was
it
like?
Ajax
requests
which,
which
ajax
requests
there
are
multiple?
Was
it
like
some
react,
rendering
stuff
that
so
to
me
that
that
high
level
span
is
is
probably
really
useful,
because
it's
the
one
that
represents
the
user's
perceived
latency
yeah.
B
E
E
Yeah
but
yeah,
it's
just
that's
such
a
bummer,
because
the
other
bummer
is
like
anytime
in
open
telemetry.
The
only
way
to
get
your
telemetry
is
as
an
app
developer
to
go
in
and
like
pack
on
a
thing
like
we
try
to.
We
try
to
avoid
that
as
much
as
possible.
We
try
to
package
up
the
creation
of
spans
and
context
up
into
some
some
framework.
That's
managing
everything
so
that
the
end
user
isn't
like
copy
pasting,
start
span
into
like
every
event
handler
they're
doing,
because
they'll.
E
B
Event
handler
like
finished
eight
years
ago,
and
it's
all
all
the
jobs
that
it
started
that
need
to
finish
so
that's
yeah,
part
of
the
like
you
know
you
can
easily
write
an
instrumentation
that
intercepts
the
the
ad
event
handler
your
attached
event
handler
and
starts
it,
but
it's
it's
the
stopping
part.
That's
the
automatically!
That's
the
problem.
A
I'm
out
of
here
have
fun.
I
have
actually
my
concern
about.
This
was
a
little
bit
different
like
we
have.
We
have
a
bunch
of
bunch
of
data
we
get
from
from
the
browser
api
that
had
that
have
durations
on
them,
but
they
you
could
they
they're?
They
don't
really
connect
through
anything.
You
know
they
can't
connect
to
backhand
spans.
They
you
can't
really
see.
The
only
thing
you
can
do
is
like
once
you
get
the
data
you
can
synthetically
like
generate
a
span
yeah.
A
E
If
they're
recorded
as
spans,
then
you
can
automatically
feed
that
into
like
a
tracing
system
and
if
they
aren't,
then
you're
gonna
have
to
know
the
name
of
every
single
event
to
to
convert
it
into
a
span
somewhere
along
the
way,
which
is
easy
enough
to
do
for
the
ones
we
know
about
right,
like
you
can
just
shove
something
into
a
collector
pipeline.
E
That
looks
for
all
of
these
things
and
converts
them.
But
if
you
make
more
of
them,
you
just
have
to
know
about
them.
All.
I
would
say:
that's
like
the
only
like
downside
right
is
if
but,
but
I
don't
have
a
strong
opinion,
because
I
think
it's
very
easy
in
a
pipeline
to
convert
these
things
from
one
to
the
other.
If
you
know
what
their
names
are,
so
yeah.
B
And
it's
also
a
case
of
the
the
events
will
have
the
the
current
span
id
associated
with
them
anyway,
so
they'll
already
be
grouped.
It's
really
case
of
I
just
see
the
additional
span
as
an
initial
grouping
mechanism,
which
may
or
may
not
be
useful,
depending
on
the
application,
depending
on
the
use
case.
E
B
E
Yeah
yeah,
I
mean
exactly
if,
if
there's
again,
I'm
just
thinking
about
like
a
tracing
tool
if
you've
got
if
there's
any
kind
of
perceived
latency
by
the
end
user,
that's
like
really
common
and
important,
but
isn't
captured
by
like
a
single
event
that
the
browser's
spitting
out,
which
I
kind
of
doubt.
I
assume
the
browser
is
spitting
out
all
the
event.
Timing
that
you
want.
But
if
it
didn't
then
that
I
don't
know,
I
would.
B
Yeah
well,
if
you're,
using
like
react
or
angular
and
it's
gonna
go
and
do
multiple
ajax
requests
to
to
maybe
fetch
a
template.
Yeah
versus
it's
already
cased
and
then
put
the
divs
on
the
screen
and
then
finish.
The
routing
navigation.
E
E
That's
I
don't
know
if
it
works
to
make
it
that
rule
of
have
that
simple
of
a
rule
of
thumb,
but
to
to
me
you
these
are
all
events,
because
that
seems
to
make
everybody
happy,
and
the
thing
where
you
know
you
have
to
have
a
span
is
any
event
handler
because
that's
doing
work
any
event
handler.
That's
doing.
Work
needs
needs
to
span
because
now
you're
gluing
together
a
bunch
of
arbitrary
stuff
and
that's
what.
E
Yeah,
if
you've
got
an
event
handler,
that's
like
on
page
load
do
a
bunch
of
stuff.
Then
you
might
want
to
span
that
that
that
bounds,
all
the
work
that
you
did
on
page
load,
because,
from
the
end
user's
perspective,
there
was
like
the
browser
loading,
the
page
and
then
there's
like
whatever
you
did
to
to
block
them
from
accessing
the
site.
E
That
was
like
your
on
page
load
handler
and
you
want
to
know
if
the
latency,
for
that
thing
is,
is
going
crazy
and
also
if
that
thing,
that's
the
kind
of
thing
that
might
be
kicking
off.
Multiple
ajax
calls
and
things
like
that,
and
so
you
want
to
see
on
page
load.
There
were
like
these
like
four
calls,
and
one
of
them
was
ridiculous,
and
that's
why
page
load
was
page
load?
Is
the
thing
you're
alerting
on
and
then
you're
realizing
page
load
is
slow
because
of
one
of
these
things
it
was
doing
that.
E
So
I
don't
know
if
that's
helpful
or
not.
I
can
only
explain
like
how
how
I
think
about
like
perceived
latency,
yeah.
B
E
B
Having
the
wrapper
or
the
overall
wrapper
groupings,
yeah,
that's
what
spams
are
called
so
yeah
yeah
and
it's
also
part
of
the
driver
behind
my
pr
there
is
to
try
and
have
it
defined.
That
attribute
use
in
general
can
be
nested,
which
is
what
the
protobuf
says,
because
I
would
ideally
like
to
say:
okay,
this
is
the
shape
of
an
event
and
we
have
the
event
api
for
that
and
all
by
the
way,
you
can
actually
do
the
same
thing
with
the
ad
event
in
spanx.
B
E
It
that
really
does
look
like
an
anachronism,
though
I
frothersworth,
I
agree
with
you
that
all
attributes
should
be
nestable
yeah,
just
anachronism
that
they
aren't
for
span
attributes.
B
E
E
B
A
B
E
Yeah
but
again
this
is
like
yeah
the
case
where
we
do
care
about
backwards
compatibility.
We
do
try
to
be
sensitive
to
the
idea
that
we're,
because
we're
like
a
standard,
we
don't
want
to
be
the
kind
of
standard
that
that,
like
really
shoves
people
around
you
know
like
we
try
to
be
sensitive
to
like
how
easy
is
the
standard
gonna
be
to
for
people
to
adopt
yeah.
So
so
I
can
see
why
that's
a
debate
there.
You
know
we
don't
want
to
be
like
well
too
bad.
You
just
have
to
deal.
E
I'm
out
of
here
too,
so
I'm
by
the
way.
Just
one
final
note,
I'm
gonna
be
so
I'm
gonna
be
gone.
My
suggestion
for
these
oteps
is
maybe
more
for
martin,
but
for
everyone
on
the
call
like
to
get
the
stuff
over
the
finish
line
effectively
be
a
squeaky
wheel
like
bother
people
on
slack
dm,
all
the
various
individuals,
tc
members,
anybody
who
might
be
helpful
to
get
it
over
the
finish
line
like
that,
that's
mostly
what
I
do
to
to
get
things
done.
E
It
does,
I
think,
make
a
big
difference
to
to
dm
people
and
not
just
not
just
keep.
So
you
don't
avoid
a
situation
where
you
just
keep
bringing
up
in
the
spec
meeting
and
then
that's
not
like
doing
anything
just
figure
out
who
you
can
get
to
put
eyes
on
it
and
then
like
keep,
keep
bugging
them
to
to
give
you
feedback.
E
E
Gonna
be
out
starting
next
week,
yeah,
I'm
gonna
be
out
starting
next
week.
I'm
going
to
be,
I
mean
I
have
a
couple
of
proposals.
You
know
that
are
still
out
there
as
prs
and
issues
and
I'm
gonna
you
know
be
responsive
to
those,
but
I'm
gonna
try
my
best
to
not
go
to
meetings,
take
on
new
work
for
the
next
three
months,
so
I'll
still
be
reachable
by
slack.
E
If
the
wheels
really
come
off
of
something,
please
let
me
know,
but
I
feel
like
y'all
y'all
are
like
pretty
boned
up
on
how
hotel
works
at
this
point
and
my
main
request
on
my
way
out
just
so
you
know
to
the
tc.
Is
I
have
this
project
planning
proposal
that
I
want
them
to
approve,
in
which
case
we'll
create
like
a
tracking
issue
for
this
one,
but
as
part
of
that
is
getting
two
tc
members
assigned
to
this
working
group,
that's
like
the
new
requirement.
E
I'm
trying
to
push
through
it's
like
none
of
these
working
groups
should
be
perpetuating
without
two
tc
members
coming
to
the
meetings
and
otherwise
being
involved,
even
if
they
aren't
domain
experts.
Just
to
avoid
this
situation,
where,
when
we
make
proposals,
it's
like,
we
rehash
the
whole
discussion
all
over
again
and
then
no
nobody
on
the
tc
or
elsewhere,
like
has
any
concept
of
it.
So
so
I
might
be
going
away,
but
hopefully
you'll
get
two
tc
members,
and
then
that
will
that
will
help
answer
questions
like.
Should
this
be
an
otep
like?
A
Yeah,
that's
where
I
think
I
feel
like.
We
need
most
help
and
that's
where
I
appreciated
you
coming
to
these
meetings
because,
like
sometimes
I
don't
know
like,
I
should
like
how
I
should
proceed
and
yes
or
if
we,
if
you
put
something
out
there
and
it
gets
like,
kicked
back
and
like
or
gets
stuck,
and
I
don't
know
what
to
do
about
it.
So
yeah.
E
Be
stubborn!
That's
that's!
That's
my
solution
if,
if,
if,
if
especially,
if
you
get
kickback
while
I'm
gone,
that
just
looks
like
people
passing
the
buck
where
it's
like
everyone's
treating
this
like
a
hot
potato
and
no
one's
like
committing
to
viewing
it
or
something
like
that,
I
think
it's
totally
fine
to
to
dm
every
individual
in
the
tc
and
be
like
hey,
we
are
stuck.
Can
you
please
unstuck
us
yeah,
be
that
mosquito
yeah?
That's
probably
again
good
feedback
with
me
as
well.