►
From YouTube: 2022-08-17 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
D
We
it
started,
I
guess
share
my
screen.
D
Okay,
yeah,
as
usual,
feel
free
to
add
any
agenda
items.
If
there's
anything
you'd
like
to
talk
about.
D
Looks
like
they
are
not
on
the
call
yet
so
I'll
just
move
right
along
last
week,
I
mentioned
that
we
were
going
to
have
a
release
for
1.2.0
of
the
API
I.
Think
the
link
is
here.
D
I
have
not
seen
anyone
with
blocking
comments
since
then,
so
I'm
going
to
go
ahead
and
merge
that
today.
So
right
now
is
your
last
chance
to
say
you
don't
think
it's
a
good
idea.
D
Okay,
I
will
also
be
releasing
contrib
packages.
Today,
I
had
been
waiting
to
see
if
we
were
going
to
have
resolution
on
the
release.
Please
stuff,
but
it
looks
like
we're
not
going
to
so
I'm
just
going
to
do
it
manually
and
I
will
do
that
this
afternoon,
again,
relatively
straightforward
everything
there.
It's
just
a
release.
Everything
has
already
been
approved.
D
The
first
real
agenda
item
of
the
day
here,
some
people
may
have
seen
I
have
a
draft
PR
to
update
all
of
our
Dev
dependencies
related
to
the
web.
Build
and
I
just
cannot
for
the
life
of
me,
get
them
to
pass,
and
it's
it's
getting
to
the
point
where
I'm
feeling
very
stuck
and
I
keep
having
to
make
changes
and
then
push
because
I
cannot
even
run
this
on
my
local
machine.
For
some
reason,
I
get
some
sort
of
permission
issue.
D
So
two
things
one.
If
anyone
has
more
webpack
experience
than
I
do
I
would
appreciate
it
if
they
would
take
a
look
at
this,
and
let
me
know
if
I'm
doing
something
wrong
and
two.
If
somebody
else
has
a
Macbook
I
would
appreciate
it.
If
you
could
check
this
PR
out
and
try
to
run
the
browser
tests
locally
because
I
don't
know
if
this
is
affecting
just
my
machine
or
if
it's
affecting
everybody's.
C
I
can
do
the
thing
where
I
test
the
web
test
locally,
because
I'm
working
on
adding
browser
support
for
like
the
Proto
package,
so
I
think
it's
probably
something
I'm
going
to
have
to
do
at
some
point
anyway.
D
That
works,
I
am
on
slack.
I
am
on
slack
I
just
found
out
recently
twice.
D
I
am
somehow
made
an
account
with
my
personal
email
and
with
my
work,
email,
so
I
guess,
if
you
ping
me
and
I
don't
respond
for
a
few
minutes,
feel
free
to
you'll,
see
a
job
in
the
list
twice
figure
out
how
to
get
the
second
account
deleted,
but
yeah
just
so.
You
know
and
that's
something
everybody
should
probably
be
aware
of.
If
you're
trying
to
reach
out
to
me
in
slack
and
I'm
not
responding
to
you,
you
may
be
sending
a
message
to
the
wrong
account.
D
D
Yeah,
but
thanks
thanks
for
looking
into
that,
and
anyone
with
webpack
experience,
particularly
updating
from
webpack
Florida
webpack,
five
I
really
feel
like
I've
been
banging
my
head
against
the
wall
on
this
one.
So
I
would
appreciate
any
help
at
all.
If
somebody
has
help
to
give.
C
D
Yeah,
this
is
at
least
our
third
try
trying
to
do
this,
so
yeah
I
mean
in
in
the
past.
We've
had
problems
where
we
updated
all
of
the
dependencies,
and
then
it
was
an
old
version
of
mocha.
So
we
had
to
update
mocha,
but
then
once
we
updated
mocha
it
didn't
support
node,
8
or
10,
and
that
was
what
blocked
it.
Now
we
don't
support
node,
8
or
10,
either
or
12
for
that
matter,
so
that
wasn't
the
problem
and
I
already
did
that
update.
Mocha
has
updated
all
of
the
node
test.
D
C
D
C
For
the
sandbox
it
it
does
use
roll
up
so
well
at
least
my
original
PR
users.
Roll
up
I
have
to
go
reconstruct
that
for
for
the
big
merge,
but
it's
it's
probably
on
the
order
of
medium
I
guess
once
I
get
it
going
in
the
sandbox
it'll
be
relatively
straightforward.
Just
put
the
changes
over
because
just
the
location
differences,
but
it's
that's
going
to
be
a
little
bit
off
time,
wise,
okay!
Well,
that's
done!
Yep.
D
I
guess
we
can
move
on
since
we're
not
likely
to
solve
this
on
the
cost.
So
just
if
anyone
finds
themselves
with
extra
time
and
has
more
experience
of
webpack
than
I
do
I
really
appreciate
feeling
well.
D
D
D
You
know
this
was
open
roughly
a
week
ago.
It
is
a
fairly
large
PR,
as
these
metrics
PRS
tend
to
be,
but
this
is
sort
of
our
last
really
large
body
of
work
required
for
GA,
so
I
would
appreciate
it.
If
people
could
review
that
and
then
we
can
work
on
trying
to
decide
when
and
how
we
want
to
go
to
juan.o,
which
I
think
is
something
everybody
wants
at
this
point.
D
Yeah
well,
genicus,
isn't
here
so
I
won't
go
too
much
into
that
Santosh.
It
looks
like
you
joined
the
meeting.
We,
we
skipped
your
your
item
because
you
weren't
here.
Yet
what
do
you
like
to.
C
Yeah
yeah,
it's
so
just
a
quick
question:
I'm
curious.
We
at
Cisco's
thinking
of
using
some
of
the
packages
under
the
experiment,
folder
in
production,
so
I
wanted
to
get
some
understanding
of
you
know
what
generally
you
folks
followed
to
in
a
movie
packages
from
the
experiment
to
the
the
non-experimental,
the
top
level
packages
folder.
D
Yeah,
so
I
can
tell
you
first
that
there
are
for
sure
some
some
hard
requirements
that
must
be
met.
Obviously
the
specification
for
whatever
component
it
is
has
to
be
stable.
We
don't
want
to
release
anything
stable
unless
the
specification
is
stable.
First
and.
D
Beyond
that,
it's
really
once
the
specification's
stable
and
we've
implemented
the
full
specification.
It's
really
a
gut
check
in
terms
of
do.
We
believe
that
there
are
large
work
items
to
be
done
or
or
not
so,
for
example,
right
now
the
otlp
exporters,
which
I
suspect,
are
the
components
that
you're
talking
about
are
marked
as
experimental,
mostly
because
for
a
long
time
we
have
wanted
to
that
they
have
all
kind
of
depended
on
each
other.
D
So
some
of
the
logic
for
the
grpc
exporter
is
implemented
in
the
HTTP
Explorer
and
in
order
to
share
logic
and
Not
Duplicate
it,
the
grpc
exporter,
depended
on
the
HTTP
exporter
and
similarly,
the
metrics
exporters
depended
on
the
trace
exporters,
and
this
is
obviously
not
something
that
we
want
long
term.
So
there's
been
a
lot
of
work
refactoring,
some
of
that
logic
out
into
the
otlp
Transformer
package.
We
recently
modified
the
protobuf
exporters
to
use
statically
generated
code
instead
of
loading,
the
proto3
files
directly
and
some
things
like
that.
D
So
those
are
like
large
changes
that
are
not
necessarily
breaking
changes
from
a
user
perspective,
but
they're
fundamental
changes,
and
we
we
don't
want.
We
don't
want
people
to
to
use
them
with
the
with
the
idea
that
they're,
complete
I
sent
I
guess
is
that
maybe
that's
a
good
word
for
it.
They
are.
We
do
consider
them
to
be
stable,
like
production,
ready
but
yeah.
So
and
that's
a
specific
answer
to
a
general
question,
I
suppose
yeah
yeah.
C
For
that
that
the
spec
doesn't
cover
instrumentation
aspects,
it's
I,
if
I
understand
correctly,
because
mostly
only
the
Telemetry
aspects,
so
with
respect
to
the
instrumentation
like
there
are
some
packages
for
instrumenting,
you
know
xhr
fetch
those
are
there
any
concerns.
Moving
to
the
non-expect
out
of
experiment.
D
D
D
But
as
far
as
I
know,
nothing
is
specifically
blocking
at
least
the
HTTP
xhr
and
fetch
instrumentations.
All
of
the
instrumentations
in
contrib
are
a
different
story,
but
the
ones
in
the
in
the
main
repository
I
would
say,
are
close
to
GA.
We
just
haven't
had
a
lot
of.
D
We
haven't
had
a
lot
of
people
asking
for
it,
and
we
haven't
had
a
lot
of
time
to
dedicate
to
it.
So
it's
just
been
a
little
bit
lower
on
the
priority
list.
C
Okay,
yeah
I
mainly
wanted
to
know
that
if
we
end
up,
you
know
using
production,
you
know
we
don't
want
any.
You
know
major
changes
to
that.
D
Yeah
I
mean
obviously
they're
in
the
experimental
directory.
They
are
not
released
as
1.0
I
cannot
guarantee
that
there
will
never
be
changes
to
any
any
package
in
that
directory.
I
can't
guarantee
that
there
won't
be
changes,
but
I
can't
tell
you
that
those
packages
have
not
changed
in
a
really
long
time
and
I.
Don't
really.
C
Yeah,
okay,
so
then
this
suggests
that
we
submit
a
PR
to
move
them
out
and
if,
if
anybody
has
any
concerns,
you
know
we
can
talk
about
them.
D
I
would
suggest
that
you
first
open
an
issue
to
review
them
for
GA
Readiness,
because
there
are
some
things
required
by
the
specification
in
terms
of
instrumentation
stability.
D
Yeah,
so
this
instrumentation
module,
which
all
of
the
instrumentations
inherit
from
is
also
in
the
experimental
directory,
so
that
would
also
need
to
be
promoted
to
stable
as
well
again.
I
think
that
for
the
most
part,
that
package
is
used
by
so
many
modules.
We
essentially
can't
make
breaking
changes
on
it
already
anyways,
so
that
I
wouldn't
expect
that
to
be
a
problem
or
a
blocker.
E
You
can
you
just
quick
quick
question:
is
the
fact
that
semantic
conventions
are
not
stable?
Is
that
potentially
blocking
these
instrumentations
from
moving
out
of
experimental?
Yes,.
D
D
Telemetry
stability:
here
we
go
so
the
Telemetry
stability
document
itself
is
experimental,
but
it
defines
what
is
an
unstable
instrumentation.
What
is
a
stable
instrumentation
and
things
like
that
I
that
the
large
answer
to
the
question
is
that
the
specification
is
not
at
a
point.
We
have
not
made
any
instrumentations
stable,
because
the
specification
has
not
gotten
to
a
point
where
we
felt
comfortable
doing
that.
D
I
think
that
this
document
is
also
not
changing
very
often
yeah,
not
since
April.
So
maybe
it's
time
to
consider
making
this
stable,
I
believe
other
sdks
have
been
treating
this
as
if
it
is
stable
and
special.
So
I
think.
If
you
look
at
the
Java
contrib,
for
example,
they
have
1.0
instrumentation
packages
based
on
this
document.
So
we
should
also
probably
mark
this
document
as
stable,
but
that's
an
issue
for
the
specification
not
for
this
meeting.
D
Yeah
so
I,
there
are
multiple
things
blocking
instrumentation
stability.
None
of
them
are
insurmountable.
None
of
them
are
that
big,
but
there's
just
here
and
there
small
things
that
have
been
open
for
a
while.
E
D
Last
week
we
talked
about
some
package
renaming
for
the
metrics
packages.
That's
done
so
I
just
wanted
to
let
everyone
know
we
renamed
the
metrics
package
to
be
SDK
metrics.
It
has
not
been
released
that
way
yet,
but
when
we
release
it
we
will
deprecate
the
old
package
with
the
opening
shouldn't
be
a
surprise
to
anyone
that
was
here
last
week
we
still
have
the
logs
and
events
prototype
Martin.
Do
you
want
to
give
us
a
quick
update
on
what
the
status
of
this
is
and
where
it's
at.
E
Yeah
I
I
did
make
an
update
to
the
API
I
think
a
couple
weeks
ago
now
so
maybe
like.
If,
if
someone
who
has
reviewed
this,
please
take
a
look
at
that
again,
specifically
on
the
shape
of
the
API
and
there's
just
there's
some
test,
failing
that,
I
need
to
fix,
but
other
than
that.
I
would
appreciate
more
more
reviews
on
this.
E
I
I
also
I
have
a
question
about
this
related
to
the
experimental
topic.
I
guess
the
specification
PR
is
still
open.
Also
for
the
API.
E
Do
we
in
in
order
for
this
to
be
merged,
proved
and
merged?
We
need
for
the
specification
to
be
merged
as
well
correct.
D
I
would
expect
so
yeah
I,
don't
I,
don't
think
it's
a
real
like
Blocker.
We
I
think
we
could
merge
this
as
long
as
we
made
it
very
clear
in
the
readme.
If
you
put
a
warning
right
at
the
top
like
this
is
based
on
work
in
progress,
specification
and
may
change,
I
mean
that's
what
the
experimental
directory
is
for,
and
the
point
of
prototypes
is
to
have
something
that
people
can
use
and
give
feedback
on
during
the
design
process.
D
So
if
we,
if
we
say
we
can't
release
anything
during
the
prototyping
phase,
then
that
limits
the
value
of
the
prototypes
I
think
base.
So
I
would
say
it's
not
necessarily
A
Blocker.
We
just
want
to
be
very,
very
clear
with
our
users
that
this
is
subject
to
change
and
it's
not
recommended
for
production
use.
Yet.
E
Okay
and
you
do
that
by
I
mean,
does
the
the
fact
that
it's
in
the
experimental
folder
is
that
enough
or
like
you're,
saying
that
we
need
to
also
make
it
clear
in
the
readme
I.
D
Think
I,
since
the
pr
has
not
even
merged
in
specification,
I
would
say
we
should
make
a
note
in
the
readme,
because
there
are
a
lot
of
things
in
the
experimental
directory.
That
can
change.
But
are
you
know
some?
D
You
know
whether
it's
25
50
or
75,
towards
stable?
There
are
different
levels
of
stability,
even
within
the
experimental
directory,
and
just
to
make
it
clear
that
this
is
this
is
based
on.
You
know
it's
different
than
than
like
the
exporters,
for
example.
To
give
the
same
example,
we
had
before
the
exporters
are
based
on
a
stable
specification,
they're
just
not
marked
stable,
yet
so
like
they're
fairly
production
ready,
and
this
is
based
on
an
entirely
unstable
specification
which
definitely
puts
it
in
a
different
category.
In
my
opinion,.
D
Okay,
next
item
we
have
here
is
build
and
test
for
Windows
targets,
just
to
make
sure
that
we
don't
merge
anything
that
blocks
people
building
on
Windows,
which
we've
done
in
the
past.
This
is
merged.
It's
passing.
It
works
I
linked
an
example
run
here,
but
there
should
be
nothing
surprising
to
anyone
in
there
mostly
just
wanted
to
let
everybody
know.
C
D
That's
there
Amir
should
we
come
up
with
a
standard
for
type.ts
in
instrumentations
yeah.
A
I,
so
someone
opened
this
PL
if
you
can
open
it,
the
first
one
so
most
implementation
says
that
type
DS
file,
which
has
a
lot
of
types
and
usually
it
contains
like
types
which
are
internal
to
the
instrumentation
that
are
used
by
the
instrumentation
TS
file
and
also
types
which
are
public
like
instrumentation
config
and
the
hooks
and
stuff
like
this,
and
currently
there's
like
a
mix
of
these
types
in
the
same
file.
And
then
things
like
this
VR
would
export
a
lot
of
the
internal
stuff.
A
And
so
what
I
wanted
to
to
ask
to
ask
is,
if
you
think
we
should
stand
up
standardize,
the
the
way
that
is
typed
yes
filed
is
used
like,
if
maybe
it
should
only
contain
a
public
types
or
maybe
we
want
to
to
decide
that
we
export
only
the
the
types
which
we
know
that
are
public,
because
if
we
will
do
it
in
the
future,
after
we
stabilize
the
instrumentations,
it
will
be
breaking
change.
I
I
think
so
it's
better
to
do
it
now
before
we
stabilize
an
instrumentation.
D
Yeah
I
think
there's
a
there
are
some
other
packages
that
have.
Let's
see
it
should
be
in
turn.
D
Maybe
I'm
thinking
of
a
different
package
I
definitely
think
we
should
only
export
the
public
types
just
to
quickly
answer
the
question.
I,
don't
think
we
should
export
all
of
the
types
even
internal
ones,
because
then
any
change
we
make
is
a
breaking
change.
D
I
would
suggest
that
we
have
like
the
types.ts
for
the
public
types
like
the
configuration
types
essentially
and
then
in
internal
types,
whether
you
call
it
just
a
file
called
internal
types
or
whether
you
have
an
internal
directory
which
contains
internal
types
and
utility
functions
and
stuff
like
that.
Either
way
is
fine
with
me,
but
I.
Definitely
don't
want
to
just
include
all
of
the
internal
Types
on
the
public
export.
D
A
D
D
D
So
I
just
got
that
update
from
them
this
morning
or
yesterday,
I
guess
technically,
but
it
looks
like
they
are
going
to
raise
the
rate
limits
for
contrib,
which
should
be
a
big
help
for
us
in
terms
of
releasing
contrib
packages.
I,
don't
know
how
high
they're
going
to
raise
it.
I
don't
know
if
they'll
just
remove
the
limit
or
anything
I
don't
have
any
anything
beyond
they're
looking
into
it
for
us,
but
just
so.
Everyone
knows
that
is
at
least
seeing
some
movement
now.
D
Ebinets
I'm.
Sorry,
if
I'm
mispronouncing,
your
name.
C
D
B
About
this
yeah,
so
I
was
trying
to
like
just
check
the
hotel,
JS
repository
and
like
I,
was
trying
to
work
with
the
participant
processor
in
browser,
but
I
see
that
only
the
node
related
participant
processor
is
exported
and
when
I
import
only,
they
are
not
as
fun,
not.
D
B
B
D
D
C
B
Yeah
the
platform,
so
that
there
is
a
node
and
this
one
only
exports
from
node,
but
the
the
there
are
by
spun
exporters,
inverse
browser
and
node.
You
can
go.
C
There,
if
you
look
in
the
package,
Json
yeah
you'll,
see
there's
a
definition
there
that
says
for
browser.
So
your
package,
you
have
to
Define
that
it's
a
browser
so
that
the
packager
knows
to
replace
those
files
with
the
browser
versions
and
that
will
solve
your
problem.
D
Yeah,
that's
exactly
what
I
was
going
to
say
that
that's
intentional,
that
only
the
node
one
is
exported
in
the
code.
The
way
that
it
works
is
it
essentially
just
replaces
the
platform
folders
with
the
browser
versions
of
them.
So
if
he's
like
build
Source
platform
index
is
replaced
with
build
Source
platform
browser
index.
So
this
sounds
like
it's
a
problem
with
the
way
that
you
have
your.
C
So
in
in
webpack
there
should
be
one
of
the
settings.
Is
you
say,
browser
equals
true,
pretty
much
the
same
for
a
roll-up
as
well,
and
that
will
tell
it
to
effectively
pull
the
the
appropriate
files.
I
will
say
it
sucks,
though
it's.
C
Not
ideal,
but
that
is
the
way
it
is
today.
C
Yeah,
if
you
look
I,
think
in
the
karma
test
for
webpack,
they
actually
do
specify
in
this
or
micro
memory.
D
B
B
Yeah
so,
which.
D
Points
you
in
the
right
direction,
if
you're
still
having
trouble,
you
can
feel
free
to
open
an
issue
on
the
repository
and
and
if
you
provide
your
webpack
configuration
and
that
sort
of
thing
there
are
people
that
can
help.
B
All
right,
okay,
I'll,
try
that
I,
don't
know
if
this
is
appropriate
here,
but
I
I
also
have
one
other
issue:
I
was
not
able
to
compile
the
some
of
the
packages
like
the
SDK
Trace
space.
It
shows
some
kind
of
error
and
I
have
actually
just
copied.
The
error
into
the
slack
Channel
and
I
haven't
got
any.
B
D
If
I
had
to
guess
it's
because
the
so,
if,
if
you're
using,
if
you've
done
a
learn,
a
bootstrap,
then
all
of
the
packages
are
linked
together.
If
you
try
to
compile
the
trace
base
and
core
has
not
yet
been
compiled,
then.
D
D
I
will
okay?
Can
you
open
an
issue
on
the
on
the
repository
and
I'll
look
into
that
after
the
meeting,
I?
Guess:
okay,.
C
D
Unable
to
manually
create
spans
in
Lambda,
oh,
this
was
created
by
Anthony.
This
was
in
slack,
so
they
are
having
a
problem
with
only
a
specific
version
of
node.
D
They
they
asked
in
slack
if
I
was
aware
of
any
problems
that
affect
node
14,
but
not
16.
I
am
not
is
it
is.
Has
anyone
here
had
issues
with
node
14.
D
They're
using
the
latest
version
of
14,
so
I
I
wouldn't
expect
it
to
be
a
problem
with
the
context
manager
but
they're
not
able
to
create
a
new
span.
I
mean
I
would
say.
This
is
definitely
a
bug,
probably
a
priority
two,
since
it's
causing
no
instrumentation
but
is
not
crashing
the
not
crashing
the
application.
D
Yeah
that
could
be,
but
I
I,
don't
know
if
it's
so
they
have.
No
new
span
is
created,
I,
don't
know
if
that
means
it's
not
created
or
if
it's
just
not
exported
I.
Suppose
I'll
try
to
reproduce
this
locally
and
in
Lambda
and
see
if
I
can
see
if
I
can
determine
whether
the
span
is
actually
created
or
whether
it's
just
not
being
exported.
A
I
didn't
read
the
issues,
but
they
had
in
the
past
issues
with
Lambda
that
didn't
flash
correctly
the
export
expense
before
going
down.
It
might
be
related.
D
It
may
just
not
be
exporting
yet
it
looks
like
they're
Sometimes
using
batch
and
sometimes
using
simple,
oh,
but
this
is
just
for
the
console
one.
So
simple
span
processor
with
the
console.
They
should
be
getting.
There's
no
asynchronous
work
here,
so
that
should
just
go
right
out.
So,
if
that's
not,
if
they're
not
getting
that
there
see,
they
didn't
include
the
logs
there's
a
lot
of
Vlogs
here.
D
In
any
case,
this
is
definitely
a
priority
too
I
just
Finance
myself,
but
if
anyone
else
has
ideas
just
because
I'm
assigned
does
not
mean
you
can't
take
a
look
at
it.
D
Soon
context
manager
breaks
spelled
kit,
life
cycle
functions,
oh
so
this
actually
turns
out
to
be
a
problem
in
zone
JS
Valentine
looked
into
this
a
little
bit.
D
D
E
A
little
bit
and
I
guess,
if
you,
if
you
disable
like
Zone,
replaces
to
Global
promise
with
its
own
implementation
of
promises.
So
if
you
disable
it,
then
some
async
context
propagation
will
probably
break
if
you
have
diffuse
promises.
D
D
I
mean
I,
don't
I
think
we're
mostly
probably
just
waiting
on
a
reply
to
this
issue
here.
So
I
guess
I
will
say.
C
C
D
C
Yeah,
but
it
probably
should
work
in
a
in
a
workout
one
of
the
goals
I
do
have
on
the
sandbox
is
not
just
make
web
tests
for
everything,
but
also
worker
tests
for
everything.
So.
D
C
C
Depending
what
else
it's
using
that
window
for
so
we'd
have
to
go
and
look
at
the
detail
but
yeah.
Sometimes
it's
as
simple
as
that.
D
C
D
We
have
us,
we
have
a
similar
like
Global,
helper
I,
believe
it's
in
core.
D
Yeah,
so
we
just
have
a
platform
specific
Global,
like
Hotel
Global
thing.
C
D
C
D
C
D
Okay,
I
guess
leaving
this
as
priority.
Four,
though,
is
probably
fine
for
now.
D
D
D
Okay,
well,
thank
you,
everybody
for
your
time
and
I
will
talk
to
you
next
week.