►
From YouTube: 2022-12-07 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
Hey
Martin
I
got
a
note
from
Ram
as
well
he's
going
to
be
about
10
to
15
minutes
late
joining
as
well
as
Santosh.
A
I,
don't
know
the
agenda
yesterday,
you
were
still
typing
it
up
as
I
joined
the
meeting.
Sorry
yeah,
yeah
I,
don't
have
anything
at
this
point.
I'm
still
doing
catch
up.
B
A
I
I
did
want
to
drill
into
the
cloud
events
SDK
question
a
little
bit,
but
the
log
singers
later
today,
so
I'll
probably
do
that
day.
I
just
didn't
get
a
chance.
Something
else
came
up
internally:
okay,.
B
Yeah
I
can
I,
don't
think,
there's
much
going
on.
Obviously
the
rest
of
this
month,
I
think
I'm
just
kind
of
planning
to
pick
things
back
up
in
January.
A
So
I
did
sync
with
ram
yesterday
afternoon:
I,
don't
know
if
it
was
late
yesterday
and
he
was
going
to
try
and
update
his
PR
as
per
what
Santosh
was
talking
about
about
a
single
page
with
the
with
them
grouped
I,
don't
know
how
far
he
got
with
that.
It
was
like
I
think
we
started
the
meeting
at
4
30
and
we
put
it
to
six.
So.
B
It's
is
that,
like
a
chain
change
to
the
open
PR
that
he
has
or
a
new
PR,
that.
C
C
No,
not
much
I
just
wanted
to
you
know
see.
If
we
can
list
down
the
exact
set
of
changes
we
need
to
make
so
that
way
now
we
can
create
a
set
of
issues
and,
and
then
you
know,
track
the
progress.
I
I
have
a
few
things
in
mind:
I
haven't
written
down
yet,
but
I
think
we
can.
We
can
do
it
right
now.
Basically,
like
yesterday,
we
talked
about
that.
The
you
know.
C
First
thing
is:
we
need
to
complete
the
logs
SDK
and,
and
then
we
need
to
let's
say
the
document
load
instrumentation.
We
need
to
make
two
changes.
You
know,
one
is
to
you
know,
pull
all
the
events
into
one
event.
The
timing,
events
and
the
second
change
there
is
to
emit
emit
an
event
page
view
event
page
impression
event
right.
So
those
two
changes
are
to
that
and
and
then
that
that
event
will
use
the
log
events
API.
A
C
Yeah
I
know
I
think
we
will
keep
the
backward
compatibility,
so
this
will
be
more
of
an
opt-in
feature
yeah.
So
the
page
view
event
you
can
emit
it's
a
new
event:
it's
not
going
to
hurt
any
of
the
existing
functionality,
but
combining
their
timing.
Events
into
one
that
I
think
we
could
do
it
based
on
a
config
parameter.
C
Yeah
the
instrumentation
config.
There
is
a
there's,
an
instrumentation
config
for
each
instrumentation,
so
we
could
add
a
parameter
to
that.
C
Changing
changing
the
existing
one
might
be
easier
and
simpler
unless,
like
you
know,
unless
you
have
a
lot
more
changes
in
mind
than
we
could
see,
if
we
want
a
new
one.
A
I
I
guess
all
the
initial
config
is
just
going
to
make
it
a
bigger
block
where
someone
will
only
be
using
one
set.
That's
all
so
I'm
just
thinking
for
a
total
bundle
size
at
the
end
of
the
day,
but
I
I
guess
yeah
have
a
go
at
hacking.
It
or
you
know
we'll,
have
somebody
go
hacking
it
and
see
how
big
it
becomes
and
if
it's
too
big,
maybe
then
split
it
out.
C
Can
you
explain
again
why,
like
what?
What
do
you
mean
by
splitting
like?
Are
there
situations
You're
Expecting,
only
one
instrumentation
is
required
and
not
the
other.
A
A
C
No
I
think
the
the
duplication
is
really
on
the
timing
events
and
that
I'm
thinking
that
we
will
give
enough
notice
for
people
to
transition
over
So,
eventually
we'll
flip
the
flag.
C
Make
the
new
one
the
default
and
and
then
you
know
those
who
need
the
previous
one,
you
know
they
should
opt
in,
they
should
choose
that
and
then
you
know,
maybe
a
year
later
we
will
remove
it.
Yeah.
A
Which
is
what
I'm
saying
like
if
it
was
a
separate
instrumentation,
they
opted
by
changing
what
instrumentation
object:
yeah,
slash
class
that
they're
using
and
we
we
can
mark
the
old
one
as
deprecated.
A
And
say
we
recommend
you
change
over
to
the
other
one,
but
a
a
little
concerned
with
yeah,
like
even
some
of
the
timelines
that
open
Telemetry
has
about
upgrading
in
one
to
two
years:
I'm
still
supporting
stuff
that
was
written
10
years
ago,
okay
and
when
I
was
in
identity.
That
was
stuck
there.
That
was
written
20
years
ago
that
we
had
to
sort
of
work.
So.
C
Okay,
yeah
I,
don't
have
a
strong
opinion,
so
maybe.
C
C
Okay,
so
why
don't
we,
you
know,
make
the
change
in
a
PR
and
then
based
on
that
change,
you
know
we
we
can,
you
know,
decide
next
yeah,
great,
okay,
okay,.
B
But
I
mean
the
the
on
the
flip
side.
I
think
I
mentioned
yesterday.
That
I
was
wondering
if
there
is
a
use
case
when
someone
would
not
want
to
have
the
existing
document
load
instrumentation,
but
only
the
logs
one.
A
Yeah
yeah
I
think
this
is
the
stepping
stone
today,
so,
okay,
so
yeah
yeah
to
take
it
to
the
extreme.
We
could
end
up
with
three.
We
could
end
up
with
the
existing
one,
the
one
where
we've
converted
it
so
that
the
span
event
is
is
all
combined
as
sent
us
talking
about
and
then
eventually
the
the
log
one.
B
B
B
Is
because
like
if
we,
if
we
update
the
existing
doc
instrumentation,
then
obviously
the
span
is
there
already,
so
we
will
see
only
the
increase,
the
increase
of
bundle
size
from
the
logs
perspective,
but
like
if
you
know
we
won't,
you
won't
see
the
difference
between
if
I
only
wanted
span.
This
is
how
big
it
was
if
I
only
wanted.
A
B
But
anyway,
in
in
any
way
we
do
this
like
we,
we
need
to
look
into
the
implication
to
size,
yeah.
A
Yeah,
it's
something
that
hasn't
happened
so
so
yeah
the
the
plan
that
I
do
have
or
that
I
did
have
in
version.
One
of
the
sandbox
was
I,
was
generating
three
additional
things.
Sorry
I
had
every
package
generating
a
bundle
so
that
I
had
some
comparisons
to
play
with
I
also
enabled
web
tests
and
web
worker
tests
for
every
model.
A
So
that's
what
I
plan
to
do
again,
but,
as
a
consequence,
I
couldn't
bring
over
every
instrument
every
package,
because
not
all
packages
run
in
a
browser.
So
that's
the
approach
I'm
going
to
take
again
just
concentrate
on
bringing
over
the
stuff
that
makes
sense
and
try
and
get
the
same
set
going
again
in
an
automated
question.
So
we
just
run
the
scripts.
A
The
module
code,
my
first
biggest
one,
is
concentrating
about
bundle
size
but
okay
yeah,
because
yeah
I
I
want
to
get
to
the
point
of
saying:
yes,
we
can
or
no
we
can't
morph
the
existing
code
to
work
in
a
web
as
well.
You
know
a
reliable
fashion.
I
suspect.
The
answer
is
no,
but
I
I
want
numbers.
A
A
The
biggest
things
I'm
concerned
about
are
the
impact
of
the
environment
variables
and
the
no-op
implementations,
both
of
which
we
don't
really
need
in
a
web
environment
Logan
if
we
morph
environment
variables
into
meta
tags
that
would
potentially
work.
It's
just
all
the
names
for
those
environment
variables
are
painful.
A
Well,
how
whether
I
can
remove
them
because
to
get
the
bubble
size
down
for
stuff,
we
don't
use
we're
going
to
need
to
want
to
remove
them
or
have
it
have
reconstruct
in
a
way
to
the
tree
shaking
removes
on
our
behalf
by
you
know,
allegedly
initializing
them
only
if
code's
accessed
or
something
like
that,
so
the
technique
I've
been
using
my
own
stuff
so,
rather
than
defining
stuff
sitting
in
a
in
a
definition
to
say,
oh
I
have
a
document
or
I
don't
have
a
document.
A
It
only
drags
that
bit
of
code
in
if
you
happen
to
reference
this
other
function.
That
wants
to
do
that.
B
C
Yeah
yeah,
yeah,
I,
I'm,
I,
think
yeah.
This
looks
like
a
good
start.
It
will,
you
know,
enable
usage
of
the
logs
SDK,
the
log
API
and
the
log
SDK.
C
So
this
looks
like
a
good
start
to
me,
but
other
than
that
yeah,
the
next
ones,
I
think
yeah,
the
other
events,
the
other
events
we
could
do
or
the
web
vitals
we
could
do
I
mean
basically
see
which
ones
to
which
ones
from
the
list
of
events
that
we
have.
You
know
which
ones
to
you
know
take
up
it.
E
C
Be
in
any
order
yeah,
but
maybe
you
know
now
that
Ram
is
online
I.
Think,
let's
list
down
the
different,
you
know
the
schema
of
different
events.
You
know
that
will
also
give
us
some
kind
of
a
plan
of
action.
D
Okay,
so
when
you
say
listen,
different
events,
what
exactly
do
you
mean
to
understand.
C
So
same
thing
same
thing:
RAM
I,
think
whatever
you
have
in
the
pr.
E
E
C
Yeah
I
think
if
we
could
start
capturing
them
and
document
yeah.
D
Should
we
look
at
the
spreadsheet
to
see
if
I
I
thought
there
were
four
events
or
something
that
we
had
already
finished
discussing
via
the
spreadsheet.
C
No
I
think
I
think
we
should
now
switch
to
you
know.
The
other
form
where,
if
we
like,
whatever
goes
in
GitHub,
is,
is
the
final
and
understood
we
could
discuss.
You
know
more
thoroughly
in
a
GitHub
PR,
because
I
think
this
spreadsheet
I
think
we
we
could
stop
working
on
the
spreadsheet,
because
I
think
it's
getting
confusing
to
me
at
least
I.
D
See
so
the
the
the
spreadsheet
is
a
useful
tool
when
we
want
to
look
at
events
from
across
the
vendors,
you
know
once
you've
passed,
that
I
think
we
can
just
work
off
of
a
regular,
PR
I.
D
Think
I
would
like
to
hear
you
know
if
others
have
any
thoughts,
I
think
it's
a
useful
tool,
but
if
there
is
a
you
know,
event
in
isolation
that
we're
creating
that
doesn't
exist
anywhere
sure
the
pr
is
about
to
go,
but
if
we
have
more
than
one
event
from
vendors
that
we
want
to
compare
and
Consolidated
to
a
single
ROM
event,
I
think
we
have
to
go
back
to
the
spreadsheet.
That's
what
I'm
thinking
and
we
don't
have
to
keep
going
back
and
forth.
D
So
it
depends
on
what
event
we
are
working
on
right.
What
is
the
next
event?
We
want
to
work
on.
Sorry,
I
came
in
late,
probably
missed.
You
know
some
of
the
conversations
happening.
C
D
Right
so
first
I
mean
you
know:
everybody
has
the
fetch
timing,
I
think
the
spreadsheet.
We
have
a
comparison,
so
that
seems
a
good
exercise
right.
Otherwise
you
have
to
have
you
know.
Everyone
needs
to
know
what
they
are
currently
capturing,
and
you
know
if
it's
being
captured
properly
in
the
new
one
or
not,
that
I
thought
it
was
useful
to
see
everything
side
by
side.
That's
the
reason
why
we
do
the
Delta
spreadsheet
I'm
not
married
to
this,
but.
C
If
it
is
yes,
is
there
anything
remaining
in
this
question,
I
know
only
the
the
let's
say,
the
the
navigation
timing
and
the
resource
timing,
I
think
that
is
incomplete.
But
yes,
the
other
ones
are
kind
of
ready
right.
D
Right,
so
we
need
to
do
let's,
let's
bring
up
the
give
it
one
second
share
screen:
I'm
sharing
my
screen.
D
So
I
think
all
of
the
Star
ones
are
done.
We
still
need
to
work
on
navigation
timing,
resource
timing,
user
action,
the
others
are
done
whatever
we.
C
I
think,
looking
at
the
pr
that
T2
has
given
me
on
on
how
the
web
vitals
are,
you
know
what
info
is
captured
it?
It
looks
like
it's
very
simple:
it's
just
a
name
value
the
name
of
the
web,
vital
and.
C
I
think
it's
new
yeah
yeah.
We.
D
A
Well,
it's
really
the
case
of.
Are
there
other
venues
that
are
doing
like
we
don't
do
it,
but
there's
anyone
else
doing
it
and
it's
probably
not
because
it
is
a
fairly
new.
Well
recent
standard.
That's
coming
again.
D
E
D
In
the
call,
do
you
guys
have
web
vitals
equivalent
or
whatever
else
stability
capture.
D
No,
it
does
okay,
so
if
you're
the
only
one,
perhaps
we
simply
just
take
that
and
they
use
it
as
a
starting
point
and
go
from
there
I
think.
Do
you
guys
think
that'll
work.
D
Okay,
I'll
leave
it
here.
If
we
want
to
use
it,
we
can
use
it,
otherwise
we
can
throw
it
in
the
pr.
So
I'd
like
to
talk
real
quick
about
the
you
know.
Pr
so
sounds
like
the
in
the
respect.
Community,
basically
said
you
know,
you
know,
is
guiding
us
to
capture
all
of
the
browser.
Events
in
a
single
file
right,
centers,
yeah,.
C
B
I'm
sorry
I
missed.
The
reason
for
that.
Is
that?
Because
currently
just
the
build
build
tools
can
support
or
is
that.
C
Yeah
the
build
tools
yeah,
so
this
is
the
page
right,
yeah
yeah.
This
is
a
build
tools.
Do
not
support
conditions
like
like.
If,
if
the
event.name
is
this
value,
then
you
know
we
should
expect
you
know
these
other
attributes.
B
D
C
Center,
no,
we
don't
I,
think
that
will
happen
eventually.
I
think
I'm
gonna
take
up
in
the
semantic
conventions
group,
okay,
where
if
we
can
Define
this
schema
like
once,
we
have
it
here,
it's
it's!
It
will
also
end
up.
Let's
say
in
the
in
the
open,
telemetry.io
websites:
documentation
like.
Can
you
open
another
tab
and
go
to
open
telemetry.io
yeah
go
there
and
then
there's
a
docs
at
the
top
on
the
left
side?
C
If
you
go
to,
let's
say
instrumentation
I
think
yeah,
so
here
I
think
we
should
like
under
JavaScript.
You
have
something,
but
maybe
somewhere
here
I
think
we
could
list
down
some
examples
of
how
the
web
apps
will
be
instrumented.
Along
with
you
know
what
events
we
containment.
C
C
So,
on
the
left
hand
side,
you
see,
instrument,
front-end
applications
and
they
have
instrument
browser,
IOS
and
Android
for
IOS
and
Android.
They
have
clearly
listed
a
heading
called
data
model,
and
so,
if
you,
you
know,
look
at
this
page,
they
have
listed,
you
know
what
are
the
you
know,
the
the
you
know
different.
D
C
D
D
What
you
would
see
over
the
wire
is
everything
listed
here:
Plus
the
default
attributes
and
basic
properties
right.
Is
that
how
you
want
to
see
it?
Okay,
correct.
C
Correct
so
now,
if
you
compare
these
tables
with
the
other
page,
you
know
you
had
to
open
the
two.
C
Yeah,
even
the
previous
step
to
that
yeah,
so
it
you
know
we
could
have
it
in
this
form.
E
C
Think
the
requirement
level,
the
last
column
may
not
be
or.
D
Maybe
we
need
this
yeah
yeah,
so
the
the
thing
that
I
don't
like
about
the
way
they
have
done
it
here
is
that
you
know
these
database
instrumentation
or
whatever
colorable
attributes
these.
These
seem
complete
to
me.
You
know
from
you
know.
Anybody
with
you
know
like
we're
getting
started
or
whatever
looking
at
this
makes
perfect
sense,
a
lot
less
data
in
MySQL,
for
example.
D
Actually
it's
an
examples.
Well,
never
mind.
I
I
think
this
is
good,
so
we
need
to
have
all
these
things.
In
my
opinion,
we
need
to
specify
what
data
type
it
is
the
description
and
samples
and
requirements
all
of
these
are
required.
In
my
opinion,.
D
So
the
somehow
we
want
to
we
want
to
tell
the
users,
you
know
consumers
of
this
dock.
You
know
always
consider
the
three
tables
or
something
like
that.
If
you
want
to
get
a
visual,
you
know
you
know
image
of
what
the
whole
event
is
going
to
look
like,
but
right,
okay,.
E
E
D
D
Right,
so
what
I'm
thinking
about
doing
is
you
know
simply
that
you
know
this
is
the
you
know,
I
started
looking
you
know
working
on
it
really
is
copy
paste
exercise.
I
was
you
know
contemplating
you
know
how
to
do
this,
so
we
would
kill
all
the
individual
MD
files
that
we
had
proposed
in
the
pr
will
probably
have
something
called
browser.md
or
something
and
list
the
fixed
attributes
and
varying
attribute
here.
D
C
Might
no
I
think
the
varying
attributes,
part
I,
think,
let's
not
add
it
at
all
right
now:
okay,.
B
C
Wait
another
you
know
few
weeks
like
two
or
three
weeks
so.
C
No,
what
what
I'm
trying
to
say
is
I
like
yesterday,
I
I
tried
bringing
it
up
in
the
you
know,
I
wanted
to
discuss
in
the
spec
meeting.
Okay,
but
I
think
the
required
folks
weren't
there.
C
So
I'll
try
again
next
week
and
and
at
least
let's
see
if
you
know
this
can
get
anywhere.
Basically,
if
we
end
up-
let's
say
by
next
month
with
the
conclusion
that
you
know,
these
attributes
cannot
make
it
to
the
resource.
D
D
C
Know
user.
C
Whatever
sorry
actually
Ram
I
think
the
the
structure
of
this
document
comes
from
yaml
files,
so
even
this
files
will
be
Auto
generated
so
on
the
left
side,
if
you
go
to,
there
is
a
top
level.
Folder
called
semantic
conventions.
Even
you.
D
C
D
E
C
C
So
so,
from
this
document
from
this
ml
file,
the
other
MD
file
is
generated.
So
you
will
be
the
process,
is
you
will
be
only
creating
this
file?
Got
it
got
it?
Okay,
right
before
you
create
the
pr
you
run,
the
is
a
Mac
commands
that
will
generate
the
empty
file
and
then
you
check
in
both
the
AML
and
the
md5.
A
C
Well,
it's
the
same
thing:
it's
it's
just
that
the
MD
file
format.
You
know
when,
when
other
people
look
at
it,
they
are
used
to
looking
at
it,
I
mean
just
to
keep
it
consistent.
If
you
do
it
through
the
ml
files,
it's
going
to
be
consistent,
yeah.
D
Ultimately,
needs
to
be
MLA
I
agree,
but
you
know
because.
D
Don't
know
I
need
to
understand
how
to
put
these
things,
because
this
is
what
I
have
in
I
have
in
my
mind
about
this.
This
is
what
I
want
the
output
to
be
right,
but
yeah
I
I
can
try
to
this,
but
this
this
definitely
is
a
little
bit
of
a
learning
curve.
Here
you
know
the
yeah,
maybe.
A
C
A
Yeah,
it's
more
a
case
of
the
yaml
tools.
Don't
support
the
affected
map
of
you
know
the
the
log
data
of
a
map
of
date.
So
defining
data
like
on
347,
we
say
extend
every
field
needs
to
have
an
extension.
It
has
to
be
one
of
the
defined
extends,
so
I
think
that's
where
you're
going
to
get
caught
up.
You
can
try,
but
okay,
okay,
I,
know
I
know
when
I
started,
defining
the
event
data
I
got
caught
up
on
that
and
had
to
just
do
the
MD
file.
D
I
thought
I
thought
this
is
why
they
basically
said
just
go
to
the
ND
directly
and
not
the
yaml,
but
if
you
think
you
can
make
it
work
on
those,
if
this
is
what
you
meant
by
taking
a
stab
at
it,
yeah
I
yeah.
D
Just
just
to
be
clear,
you
know
completely
with
you.
Ultimately,
you
know
we
want
to
be
consistent,
defended
in
the
MLM
things,
but
to
get
going
and
you
know
get
the
things
you.
D
Effect
out
State
we
can
do.
This
is
what
I
was
saying,
but
I'm
finding
that,
if
you're
able
to
help
out
with
this
sure.
C
Okay
yeah,
so
then,
why
don't
you
you
know,
give
me
some
time
a
couple
days:
okay,
yeah.
E
C
Oh
okay,
oh
is
it
okay,
yeah
I
mean
I.
I
was
going
to
bring
up
the
topic
and
and
then
essentially
say
that
you
know
from
From
ramsig's
perspective.
We
have
what
we
want
like
we.
We
will
continue
with
the
events
API,
that
that
is
part
of
the
current
spec.
As
of
today,
we
will
proceed
with
event.data.
C
You
know,
I'll,
ask
Jack
and
the
grin
to
continue.
You
know
from
their
side.
You
know
the
the
you
know,
having.
E
C
For
yeah
having
support
for
map
attributes
for
all
signals
and-
and
then
at
some
point-
if,
if
that
is
not
going
anywhere,
then
we'll
modify
the
build
tools
to
enable
adding
event.data
to
the
specifications
only
from
logs
perspective
right
and
so
with
with
those
things
I
think
we
don't
need
anything
else
like
even
the
schema
aspects.
We
are
not
like
super
dependent
on
them.
As
of
now
you
know
we
we're
not
doing
any
machine
based
validation
of
schema
as
of
now
yeah.
C
We
will
we
will
get
to
that
eventually,
but
for
our
for
for
us
to
get
started
with
the
implementation,
we
are
not
blocked.
Yeah.
C
That
we,
we
are
good
from
cloud
events
perspective
actually
I
reached
out
to
somebody
in
Cloud
events.
They
they
agreed
to
come
to
the
you
know
loxic,
but
they
are
asked
us
to
first,
you
know
create
an
issue
in
their
GitHub,
providing
some
details
which
I
haven't
done,
but
I
think
that
that
will
happen
separately,
I
and
I.
Don't
think
we
we
should
be
blocked.
A
Yeah
because
it
was
really
I
think
we
should
have
a
mapping
of
cloud
of
the
cloud
events
spec
into
a
log
record,
yeah,
I'm,
I'm,
a
little
hesitant
to
say,
open
Telemetry
will
take
the
cloud
events
SDK
and
say:
that's
it
yeah.
C
So
that
that
point,
I,
that
also
you
know
I-
can
bring
up
I'll
tell
them
that
you
know
we
will
evaluate,
but
there
are
two
issues
as
of
now,
you
know
one
is
that
the
bundle
size
you
know
is
going
to
become
bigger,
so
it's
a
primitive
yeah
and
also
you
know
they
don't
support
a
separate
domain
parameter
which,
which
you
know,
even
though
the
ramsig.
It's
not
a
rum
six
concern,
but
the
log
Sig
events
spec,
you
know,
need
since
it
needs
to
support
events
from
multiple
domains.
C
C
B
Okay
thanks:
everyone
thanks.
D
Everyone
sometimes,
if
you
know,
if
you're
working
on
the
yaml
file
and
you
know,
want
you
know
a
combined
session
or
something
like
that.
You
know
ping
me
I.