►
From YouTube: 2022-05-25 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
B
All
good,
like
like
huge
thanks
for
doing
this,
it
doesn't
solve
our
problem,
though.
Like
next
time
we
are
going
to
have
a
release.
We
will
most
likely
be
in
the
same
situation.
C
Yeah
definitely
the
same
situation,
I'm
I
was
looking
into
what's
going
on,
but
I
think
probably
release.
Please
just
needs
to
be
updated
because
github
returns
like
the
the
headers
that
say
how
many
requests
you
have
left
in
your
like
rate
limit,
so
it
should
probably
just
be
updated
to
slow
itself
down
when
you
are
running
out
of
requests.
C
B
Created
an
issue
or
two
somewhere
in
the
realm
of
release,
please
as
well,
but
I'm
not
sure
whether
I've
heard
back
from
them
no,
not
and
actually
like
to
be
totally
honest.
I
I
haven't
validated
whether
ray
limming
thing
is
the
issue
I
just
assume
it
is,
but
we
don't
have
any
any
definite
proof
of
that
right.
C
Okay,
I
think
we
can
probably
get
started.
C
Do
we?
Oh
there
was
an
agenda
item
here.
Oh
I
see
you
just
moved
it
down
cool
all
right.
So
first
thing
is
the
open
telemetry
community
day.
Can
you
guys
see
my
screen?
Yes.
Okay.
First
thing
is
the
open,
telemetry
community
day
same
thing.
I've
said
for
the
last
several
meetings.
I
will
be
there.
C
I
think
amir
said
he'll
be
there
as
well,
so
for
anyone
who
doesn't
already
know
june
20th
in
austin
texas,
I
hope
to
see
as
many
of
you
as
I
can,
so
I'm
actually
going
to
move
this
down
to
the
metrics
rc
topic.
Andy.
C
C
C
We
just
make
the
changes
that
we
need
so
that
it
works.
I
think
the
the
client
instrumentation
sig
is
taking
it
more
as
a
rewrite
like
a
browser-specific
client
that
won't
have
a
node
and
browser
compatibility
code.
It'll
only
work
in
the
browser
yeah,
oh
perfect,
yeah,.
E
Yeah,
so
the
the
approach
that
we
will
be
taking
at
some
point
is
what
daniel
just
said:
well,
we'll
actually
rewrite
the
sdk
from
a
web
point
of
view,
so
the
plan
will
be
to
keep
the
api
but
then
go
and
create
a
a
web
sdk
which
only
includes
components
necessary
for
the
web,
and
it
will
be
built
to
be
as
minifiable
as
possible.
C
Will
you
reuse
the
packages
that
we
have
that
are
already
cross-platform
or.
E
So
so
the
the
original
approach
would
be
to
grab
what's
already
there
and
hack
it
to
make
it
small,
hopefully
keep
it
compatible
so
effectively.
You
can
load
an
instrumentation,
that's
not
necessarily
built
for
web,
but
it
would
work
if
you
could
look
if
you
load
it
into
a
browser.
I
think
martin
and
martin
here
yep
martin
and
probably
my
myself-
will
probably
look
at
creating
some
sort
of
prototype
and
investigate.
C
So
the
initial
version
will
use
at
least
some
of
the
components
that
we
publish
and
then
potentially
rewrite
them
specifically
for
the
browser.
Later
is
what
you're
saying.
E
E
Yeah
great
but
yeah,
but
my
view
would
be
just
to
grab
it.
Do
it
in
a
branch
to
prototype
it
and
then
go
from
there
and
start
the
process
of
what?
How
do
we
make
this
live
in
this
one?
Or
do
we
split
that
into
a
separate
project.
F
Okay,
the
other
thing
that
I
would
that
I
want
to
highlight
is
the
that.
The
thing
that
we're
working
on
in
the
client
side
sig
is
orient
like
changing,
changing,
introducing
a
signal,
a
different
signal
for
for
a
client
side
as
an
event.
So
the
the
current
instrumentation
in
in
the
js
sdk
is
all
based
on
spans
and
we
are
planning
to
heavily
make
use
of
events.
C
Yeah
but
that's
that's
an
instrumentation
change,
yeah.
C
C
E
Santosh
already
has
a
proposal
for
the
event
api
out
there.
It's
getting
discussion
already
so
effectively
it's
going
to
be
backed
by
logs,
but
it
will
be
a
well
depending
how
the
discussion
goes.
It
will
either
be
a
separate
api
or
an
extra
entry
point
into
the
logs
api,
okay,
which
the
api
doesn't
strictly
exist
yet
because
it's
all
the
connections.
G
Yeah,
I
think
so
like
overall
just
trying
to
get
a
feel
for
what
the
plan
is
there,
and
you
know
if
we
were
to
start
prototyping
any
sort
of
like
rum
solution
in
alignment
with
you
know
open
telemetry,
you
know,
what's
the
best
starting
point,
I
guess
is
ultimately
what
we're
getting
at
and
I
wasn't
sure
the
state
of
those
in
particular.
C
Yeah,
if
you're
planning
on
wrong
so
like
making
rome
solutions,
I
assume
you
mean
for.
C
Yeah,
I
would
completely
agree
like
that's.
That's
the
right
way
to
go
about
that,
and
I
would
say
that
we
in
our
sig
at
this
point
are
unlikely
to
look
into
rum,
since
we
know
that
the
other
sega
working
group
is
already
working
on
that.
I
guess
those
efforts
may
be
potentially
somewhat
merged
in
the
future,
but
for
now
they're
pretty
separate.
G
Yeah
I've
been
attending
at
the
rum
stick
as
well
occasionally
but
figured
I'd
check
in
since
this.
This
piece,
part
of
the
current
hotel,
jazz
repair.
E
Thanks
yeah,
probably
from
I've,
tried
a
couple
of
times
both
with
a
an
intern
and
myself
to
make
the
js
sdk
work
in
a
browser,
and
it
always
ended
up
being
too
big.
So
size
is
always
a
is
always
problematic
for
us
anyway,
and
it
has
like
you
know,
hardly
any
functionality,
and
then
the
biggest
problem
I
hit
was:
how
do
we
get
events
from
the
client?
C
So
do
you
have
it?
It
may
be
too
early
in
the
process
to
answer
this,
but
when
you
say
it's
too
big,
so
you're
going
to
to
obviously
then
make
it
smaller
is
the
is
the
idea
what
types
of
things
do
you
think
you
will
be
removing
in
order
to
make
it
smaller.
E
E
C
C
G
I'm
sure
it's
a
deep
topic.
I
don't
know
andrew
how
president
you
are
here.
If
you
have
any
specific
things
you
want
to
ask
on
top
of
that,
but
but
that
gives
me
a
better
idea.
You
know
part
of
what
we're
trying
to
do
is
get
a
feel.
For
you
know,
what's
realistic,
you
know
to
potentially
help
contribute
versus
you
know.
What
we
need
to
do
is
kind
of
a
stop
gap
for
for
a
solution,
we're
looking
for.
D
C
Okay,
so
I'll
move
on
to
the
next
topic.
I
guess
for
those
that
don't
know.
Last
week,
just
before
kubecon
started,
I
we
attempted
to
release
the
contrib
packages
with
an
update
that
happened
to
touch
most,
if
not
all,
of
the
packages.
I
think
because
dependencies
were
being
updated
and
the
release.
C
Failed,
we
don't
know
exactly
why,
but
our
best
guess
at
this
point
was
that
we
hit
some
sort
of
rate
limit
on
github
because
or
or
on
mdm,
because
we
that
our
release
automation,
creates
a
release
for
every
single
package
and
then
also
comments
on
the
pr
for
every
release
that
it
creates.
C
So
I
don't
remember
exactly
how
many
packages
we
have,
but
it's
quite
a
few.
So
that's
a
lot
of
api
requests
in
a
very
short
period
of
time
in
order
to
get
through
this.
For
now
I
released
all
of
the
packages
manually,
but
this
will
happen
again
in
the
future,
so
we
will
probably
have
to
look
into
some
sort
of
rate
limiting
on
our
release.
Automation.
C
I
have,
in
the
past,
created
issues
on
the
release.
Please
automation,
tool
that
we
use
and
they
are
typically.
C
Fairly
responsive
and
fairly
open
to
the
idea
of
making
changes,
so
hopefully
this
is
something
that
they
will
handle
on
their
end,
but
I
just
wanted
everybody
to
be
aware
that
was
kind
of
why
the
release
was
delayed
a
little
bit.
C
The
only
package
that
I
did
not
release
is
the
docker
resource
detector,
because
the
package
json
for
that
has
it
marked
as.
C
1.0-
and
I
think
that
that's
incorrect,
but
I
wanted
to
check
with
I
don't
know
who
authored
this
package.
Ronno.
Did
you
initially
author
this
package?
I
think
I
did.
I
I
I
can
make
that
change
to
0.1.0.
If
that
is
necessary,.
C
I
think
that
we
probably
should
just
this
is
the
initial
release
of
this
package,
and
if
there
are
any
major
problems
with
it,
I
think
that
we
want
to
make
sure
that
we
catch
them
early.
C
You
know
before
we
release
the
1.0
if
possible.
Also,
I
am
not
entirely
sure
what
the
state
of
the
semantic
conventions
is
around
these
resource
attributes
and
whether
the
semantic
conventions
have
been
marked
as
stable.
B
Okay,
yeah,
actually
just
a
quick
comment
on
that
in
the
pr
we
actually
decided
to
make
it
0.1
and
the
original
author
kindly
made
the
the
change
but
release.
Please
pumped
it
to
1.0
right
away,
and
we
also
had
a
discussion
on
that,
but
I
was
unable
to
actually
fix
and
make
it
so
that
it
doesn't
pump
it
to
1.0
but
0.2.
B
Generally,
like
I,
I
wouldn't
you
know
fit
about
us
making
stuff
like
1.0,
especially
the
smaller
components,
because
they
don't
have
to
be
versioned
in
box.
Step
with
other
stuff
detectors
are
quite
small,
and
I
I
do
think
that,
like
the
comment
about
semantic
conventions
is
important,
because
we
don't
want
to
release
something
like
that.
B
We
state
is
stable,
but
we
know
that
we'll
break
stuff,
but
other
than
that,
I
think
if
the
component
is
known
to
be,
you
know
stable
enough
and
it
is
a
small
component
like
I
don't
see
a
issue
releasing
1.0
and
at
some
point
releasing
two
point,
something
because
I
don't
know
like
it.
Just
I
don't
see
a
good
benefit
like
they're
holding
the
holding
everything
in
the
zero
point
range.
C
Okay
yeah,
I
I
agree
that,
especially
for
the
the
plug-in
components
going
to
1.02.03.0
is
not
a
problem.
I
do
think
that
we
should
probably
hold
things
at
least
until
the
semantic
conventions
are
stabilized.
C
Okay,
it
looks.
B
A
C
So
this
is
about
the
core
revo
I
just
wanted
to
mention.
I
think
that
we
should
do
a
a
release
of
core
this
week.
So
after
this
meeting
I
will
create
a
release
pr,
you
know
same
thing.
We
we
normally
do.
Please
comment
on
it.
C
If
there's
any
issues
that
you
think
should
block
the
release,
there
are
two
that
we
have
already
identified
mark
and
I
were
looking
at
it
before
the
meeting
the
default
instrument
unit
that
andy
the
pr
that
andy
opened,
and
there
is
a
pr
on
the
transformer
package
just
to
make
sure
that
it
is
properly
packaged
when
we
release
it,
but
when
those
two
are
merged,
I
think
we
should
be
able
to
make
a
release,
and
I
believe
that
we
should
be
good
to
consider
that
as
a
release
candidate
for
metrics,
so
I
will
I'll
create
that
pr
after
the
meeting,
if
anybody
knows
of
any
issues
off
the
top
of
their
heads
now
that
that
should
block
this,
please
let
me
know-
or
if
you
think
of
something
later,
please
add
it
to
the
release.
C
C
C
C
I
have
been
hoping
that
valentine
would
be
on
the
call,
since
I
think
he
was
the
one
that
initially
implemented
this.
But
since
he's
not
here,
I
will
probably
look
into
this
this
afternoon
unless
somebody
is
really
feeling
like
they
want
to.
C
Otherwise,
I
will
just
assign
myself
here-
yeah,
not
a
lot
to
say
about
that
other
than
look
out
for
that
pr.
C
Okay,
so
we
already
talked
a
little
bit
about
the
metrics
release
candidate.
We
talked
about
these
two
issues.
The
only
thing
that's
left
is
the
same
thing
I
mentioned
two
weeks
ago.
C
There
are
a
couple
of
subtasks
on
the
prometheus
exporter,
which
need
to
be
done,
which
should
be
relatively
yeah,
not
not
necessarily
easy
tasks
but
straightforward
with
straightforward
requirements.
C
So
the
the
big
one
is
the
adding
resource
support
into
the
prometheus
exporter,
which
is
now
required
by
the
spec.
So
if
somebody
wants
to
take
that,
please
comment
on
that
issue
and
I
will
make
sure
it
is
assigned
to
you.
C
Okay,
sort
of
on
just
an
informational
note,
because
the
sotep
has
already
merged.
But
for
those
that
aren't
aware
there
is
a
new
concept
which
are
being
referred
to
as
scope
attributes.
So
we
have
the
instrumentation
scope,
which
was
a
renamed
property
that
used
to
be
the
instrumentation
library.
B
C
Agree
with
him,
so
this
hasn't
happened
yet
because
the
dotep
has
merged,
but
there
isn't
a
specification
pr
yet
or
at
least
it's
not
merged,
but
just
for
the
record
that
will
be
coming
in
the
future.
A
A
C
C
I
don't
think
they
have
to
be
grouped.
I
think
we
can
export
two.
C
A
D
C
I
think
if
we
see
that
people
are
having
performance
issues,
then
we
can
look
into
that,
but
the
the
comparison
itself.
D
D
A
I
think
most
cases
the
tracer
will.
A
A
D
C
H
C
H
C
H
C
H
Attribute
in
the
spec
and
see
how
the
other
spec
authors.
C
All
right,
I
just
like,
I
usually
do
created
a
list
of
new
prs
since
the
last
meeting.
So
please
take
a
look
at
those.
They
are
in
need
of
reviews
and
there
are
a
few
old
pr's
that
have
been
around
for
a
while
that
are
also
in
need
of
reviews.
C
Aaron
are
you
on
the
call?
I
was
gonna
ask
about
yours.
C
No
he's
not
here
this
one
in
particular,
the
synchronous
resource
detection
probably
is
not
ready
for
reviewing,
but
all
the
others,
I
think
are-
are
good
to
go.
C
Yeah,
I
mean
it's
totally
up
to
you.
We,
the
the
aws
sdk
instrumentation,
is
under
our
scope
because
it's
published
out
of
our
repo,
the
azure
and
google
instrumentations
or
components
they
decided
to
host
in
their
own
repositories,
which
comes
with
obviously
advantages
and
disadvantages.
C
C
So
if
you're
looking
for
external
prs
and
pr
reviews,
you
know
on
your
own
repo
you'd,
be
you
need
to
to
work
on
that
on
your
own,
to
get
visibility
of
those,
but
I
don't
think
we
make
a
recommendation
either
way.
I
think
it's
up
to
you.
C
I
don't
know
yeah,
I'm
honestly,
not
sure.
C
E
Yeah
for,
like
the
azure
one,
I
think
there's
internal
mandate
that
we
have
to
have
our
own
stuff
there.
So
I
think
that's
why
it's
in
that
azure,
not
on
open
telemetry.
C
Okay
sounds
good
yeah
and
then,
at
least
from
an
end
to
user
perspective,
it
certainly
seems
a
lot
more
official
to
pull
it
down
from
the
azure
scope
like
if
I
was
an
end
user
and
I
was
instrumenting
an
azure
component
and
I
pulled
it
down
from
an
azure
scope.
I
think
I
would
have
a
lot
more
confidence
that
it's
you
know
correct
and
stable
and
all
of
that
stuff
who
would.
J
It's
not
about
like
it's
about
where
the
code
lies.
So
even
if
aws
sdk
instrumentation
code
lies
in
open,
telemetry
scope,
aws
sdk
maintainers
may
contribute
to
it.
C
Yeah,
I
know,
but
as
an
end
user,
when
I'm
installing
something.
If
I
pull
it
down
from
theo,
the
aws
scope,
then
you
know,
I
think
I
would
have
more
confidence
in
it.
That's
that's
just
a
gut
feeling.
It's
obviously
not
you
know.
There's
no
official
policy
around
that.
C
I
don't
I
mean,
I
know
that
we
don't
have
any
specific
recommendation
published
for
javascript.
I
don't
know
if
any
other
clients
have
or
any
other
cigs
have
made
their
own
recommendations.
C
J
C
I
would
honestly
reach
out
to
maybe
ted
suho
on
slack,
since
he
has
done
a
lot
of
the
work
around
like
versioning
and
packaging,
and
things
like
that
for
the
overall
for
open
telemetry
in
general,
not
just
for
js,
and
he
may
be
able
to
to
help
you
to
come
up
with
a
policy
or
to
decide
if
there
should
be
an
official
policy
or
recommendation
that
applies
to
all
the
sigs
or
if
this
is
something
that
we
should
just
work
on
for
open,
telemetry
jas
and
then
not
worry
about
other
sigs.
C
J
C
Anybody
else
have
anything
to
add
to
that.
I
know
we
don't
haven't
really
talked
much
about
this
in
the
past.
A
J
Actually
I
spoke
with
aws
x-ray
folks
who
actually
wrote
this
library,
I'm
from
abella
st
for
javascript.
J
G
J
Review
dual
packaging
solution,
a
link,
so
node.js
recommends
two
solutions.
One
is
esm
wrapper,
which
is
approach,
one
that
is
publish
everything
in
suggest
and
add.
Asm
wrapper
second,
is
isolate
state
that
is,
provide
an
export
map
where
the
required
tells
where
the
cgs
code
is
and
import
tells
where
mg
score
is.
J
J
There
is
instrumentation
node
module
file,
which
takes
a
particular
file
path,
so
here
we
just
need
like
no.
If
any
consumer
of
open,
telemetry
js
instrumentation
uses
this,
they
have
to
explicitly
tell
where
the
file
path
is,
and
if
library
authors
has
cjs
and
mjs
files,
they
cannot
use
this.
C
C
C
C
The
instrumentation
node
module
file,
I
think,
is
there
a
way
for
it
to
select
a
common
js
or
esm
based
on
the
type
of
application.
I
don't
know
the
answer
to
that
question.
C
C
But
I
know
that
there's
a
couple
that
do
they
would
also
have
to
have
essentially
two
versions
of
that,
because
the
in
common
js,
I
believe
I
you
pass
without
you're,
using
the
full
the
full
path,
including
the
file
extension,
which
would
be
different.
The
path
and
the
file
extension
would
both
be
different
for
dual
published
packages,
and
you
probably
could
just
list
both
options
in
the
instrumentation
node
module
file
list,
because
one
of
them
would
be
triggered
and
the
other
one
would
just
not
be
triggered.
C
But
I
am
not
100
sure
about
that.
That's
just
an
educated
guess.
J
So
I
shared
a
link
of
how
aws
sdk
instrumentation
uses
instrumentation
known
module
file
in
a
chat
window.
J
C
J
So
yeah,
because
it
it
will
matter
for
browser
and
node,
also
right,
so
some
packages
have
different
file
for
browser,
different
artifact
location
for
browser
and
different
artificial
location
for
node,
so
that
kind
of
solution
would
help
packages
which
support
multiple
environments.
J
C
Yeah,
I
would
say
probably
we
could
extend
this
api
to
accept
a
list
of
strings,
but
I
don't
know
for
sure
that
it
would
work.
But
that's
my
that's
my
immediate.
J
Where
should
I
follow
up?
Should
it
be
a
github
issue
on
open
telemetry.js.
C
J
C
Yeah,
I
assume
these
are
the
ones
you
added
up
here.
Yes,
yeah
thanks,
I
mean,
I
think,
that's
a
great
idea.
It's
just
something
that
nobody
has
done
before.
There's
there's.
C
I
think
that
yeah,
unless
there's
a
different
class
of
people
that
are
not
users
and
also
not
contributors,
I
think
that
those
are
the
two
places
that
I
would
typically
point
people
towards.
If
I'm
missing
anything,
we
can
always
add
more.
C
C
All
right,
I
that's
the
full
agenda
for
the
day.
Anybody
have
anything
that
they
feel
like.
We
didn't
cover
that
they'd
like
to
bring
up.
Now
we
have
about
15
minutes.
C
Okay,
well,
that's
the
case,
look
out
for
the
release
pr
I'll
create
that
this
afternoon,
and
otherwise
I
will
talk
to
everybody
next
week.