►
From YouTube: 2022-07-13 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
B
Was
it
still
good?
Did
you
eat
it.
A
It
was,
it
was
still
good
just
in
instead
of
getting
like
20
small
ones.
I
got
one
big
cookie.
C
All
right
just
a
quick
reminder
that
I
am
out
july
27th.
I
mentioned
it
last
time,
but
that's
two
weeks
from
now.
The
meeting
will
at
this
point
likely
be
cancelled
because
rauno,
I
know
you're
out.
I
think
valentine
is
also
out
that
week
and
mark
is
out.
So
we
don't
have
anyone
to
run
the
meeting.
So
the
meeting
will
most
likely
be
canceled
that
day
unless
something
changes.
B
Weeks,
yeah,
maybe
the
one
after
it
as
well,
I'm
not
sure
without
it.
C
First,
real
item
we
have
is
we
received
a
complaint
about
the
1.4.0
release?
I
know
at
least
valentine
saw
it
because
he
reacted
to
my
response.
I
wanted
to
just
mention
it
there's
nothing
at
this
point
that
we
can
do
about
it
and
we
kind
of
knew
that
this
was
going
to
happen,
and
my
response
was
essentially
that
we
we
talked
about
this
for
a
while.
We
didn't
take
the
decision
lightly,
but
at
this
point
it
is
what
it
is.
C
I
just
wanted
to
bring
it
up
just
so
that
people,
particularly
the
other
maintainers,
are
aware
yeah.
Maybe
in
the
future
we
can
be
more
explicit
about
documenting
our
deprecation
policy
for
a
for
a
longer
period
of
time.
I
think
we
should
we
should
document
what
the
policy
is,
because
I
think,
eventually
we're
going
to
have
to
deprecate
node
14
and
we're
going
to
have
probably
the
same
issue.
C
So
if
anyone
has
questions
about
what
the
actual
complaint
was
about,
essentially,
if
you
look
at
the
linked
issue
here,
let's
see
we
have
it's
passing
now,
so
we
have
to
find
an
old
version
of
this.
C
I
believe
it
was
this
one,
so
on
node
12
they
run
with
this
like
engine
strict,
so
they're
testing
in
node
12..
When
they
installed
the
semantic
conventions
package
version
1.4.0
it
broke.
We
sort
of
knew
that
this
would
happen.
They
solved
it
by
pinning
to
1.3.1,
which
is
obviously
not
ideal,
but
they're,
also
in
the
process
of
deprecating
node
12
on
their
end
as
well.
C
I
don't
know
if
there's
anything
we
can
do.
I
don't
think
there's
anything
we
can
do
about
this
at
this
point
and
we
did
kind
of
know
that
something
like
this
might
happen,
but
I
just
wanted
to
make
sure
everyone
was
aware
anyone
have
questions
before
I
move
on
there.
C
C
C
And
there's
a
handful
of
pull
requests
that
need
to
be
reviewed.
I
did
remove
all
of
the
pull
requests
from
the
milestone
because
having
the
issue
and
the
pull
request
in
the
milestone
didn't
make
sense,
it
was
just
duplicating
for
no
reason
it
made
it
more
difficult
to
track
the
work.
C
C
The
two
that
virt
has
opened
have
been
sitting
for
a
while,
but
he
did
mention
a
couple
of
days
ago
that
he's
been
busy
and
he
just
started
picking
up
work
on
those
again.
So
that's
good.
The
other
three
are
all
open
by
mark
mark.
Are
there
any
of
these
three
prs
that
you
want
to
talk
about
right
now
or
just
generally,
do
you
want
reviews.
D
C
D
Up
here,
yeah
that
that
changes
quite
a
bit
with
regards
to
views,
we
talked
about
it
in
the
last
sick
meeting.
Already
it
just
moves
the
the
view
configuration
to
the
meter
provider
constructor.
So
you
would
have
to
instantiate
the
view
and
then
then
pass
it
there
yeah.
That's
that's
basically
the
short
story:
okay,.
C
Okay,
let's
move
on
to
the
api
attach
and
detach
we've
called.
We
we've
talked
about
this
a
couple
of
times
today.
I
want
to
talk
about
a
proposal
that
florna
made.
C
B
C
Yeah,
I
think
that
that's
likely
to
be
a
little
bit
confusing
just
in
terms
of
documenting
that
you
can
either
just
call
the
function
or
pass
it
to
the
detach
method,
and
things
like
that,
I
I
don't
know
if
users
are
likely
to
be
confused.
B
C
E
C
Pr
is
just
for
a
convenience
api.
It
was
created
by
phil
carter
from
honeycomb.
C
It
is
reviewed
and
approved
by
all
the
maintainers,
except
for
me,
the
only
thing
that
we're
waiting
on
here
is,
let's
see
back
to
the
issue
I
suggested
renaming
it.
Instead
of
where
did
the
issue
go
162.
C
instead
of
get
current
span
using
getactivespan,
because
we
tend
to
use
that
active
wording
everywhere.
It
looks
like
he
responded
to
that
yesterday,
but
has
not
yet
actually
updated
the
pr,
but
once
that's
updated.
I
I
think
I'm
going
to
merge
that
unless
anybody
has
any
objections.
C
Okay,
we
have
a
few
metrics
prs
in
need
of
reviews.
These
are
actually
the
same
that
we
talked
about
when
we
looked
at
the
milestone.
C
I
think
we've
talked
about
all
of
them
already,
but
I
just
added
them
in
the
list
here
since
they're
they're
high
priority
for
metrics
ga,
and
just
please
review
these.
When
you
have
time,
I
don't
really
think
we
need
to
talk
about
any
one
of
them.
In
particular,
I
added
the
the
short
keys
for
the
otlp
jason
back
into
the
agenda.
C
C
I
need
to
get
caught
up.
Okay.
I
know
that
nev
has
been
yeah
fairly
active
here.
He
also
gave
us
quite
a
bit
of
good
context.
Last
nev
week
you
have
a
good
feeling
on
which
way
the
wind
is
blowing
on
this,
whether
they're
planning
on
adopting
this
or
not.
F
I
I
think
it's
leaning
towards
no
but
like
if
it's
gonna
go
as
it
is.
I
I
I
prefer
I
think
oberon
is
in
there
saying,
use
the
numeric
value
instead
of
the
creating
short
keys,
but
I'm
proposing
a
completely
different
approach
so
because
I
know
that
there
are
some
protobuf
converters
which
will
convert
it
into
a
into
more
of
a
flatter
definition
like
I've
got
there.
I
don't
know
what
we
have
today.
C
Okay,
yeah,
and
I
know
that
oberon
suggested
that
very
early
on
just
using
the
numbers.
Another
proposal
that
I've
seen
floated
was
creating
a
separate
protocol,
specifically
to
be
a
lightweight
json
protocol,
instead
of
instead
of
modifying
the
existing
json
protocol,.
F
Yeah
and
that's
sort
of
what
I'm
suggesting
here
with
the
aprons
is
create
something
have
a
different
attribute
type,
which
is
just
key
value
as
an
object,
rather
than
an
array
of
objects,
got
it.
Okay,.
C
F
C
Right
so
I
guess
your
your
feeling
is
that
the
the
proposal
as
it
stands
is
not
likely
to
be
accepted,
but
they
probably
will
do
something.
F
C
C
Keys,
I
think
the
biggest
problem
is
that
the
json
payload
size
can
be
quite
large
when
it's
not
compressed.
B
F
Keys
you,
you
can
do
it
independently,
like
for
identity
as
part
of
the
api,
there
is
a
bunch
of
version,
specific
programmatic,
short
keys
that
get
generated
on
the
fly.
You
do
have
a
thing
called
message
pack,
which
can
be
used
which
is
sort
of
like
gzip,
but
a
bit
lighter
weight,
but
it
has
issues
as
well
and
then,
if
you're
not
sending
a
lot
of
repeated
stuff,
it
actually
creates
a
bigger
payload
than
if
you
don't,
but
it's
still
in
json
format,
yeah,
it
made
very
it
really.
F
If
you
look
at
the
example,
outputs
that
tigran's
got
there,
it
really
highlights
the
problem
because
we
have
attributes
that
have
objects
which
have
objects.
You've
got
a
specified
like
key
which
is
redundant
and
then
value
which
is
redundant
and
then
the
type
which
is
redundant
yeah.
E
B
But
I
think
it's
very
for
for
browsers
to
communicate
with
the
backend
servers
with
the
json
like
this
is
the
standard.
C
C
I
I've
definitely
seen
cases
both
internally
and
at
other
places
where
the
where
json
has
been
shortened
by
by
modifying
the
keys,
it's
it's
fairly
common
with
very
high
volume
apis.
But
then
I
also.
G
G
I
I
would
just
add
to
that
that
it's
like
you
know,
obviously
people
can
implement
what
that,
whatever
they
want
in
their
applications
but
but
like
as
as
like
a
third
party
analytics
library.
That's
like
not
not
key
like
not
not
like
critical
to
each
application
like.
We
should
try
to
optimize
that
so
that
it
doesn't
send
huge
amount
of
data.
E
There's
just
a
difference
of
if
we're,
if
you're
talking
about
just
an
application
that
someone's
going
to
develop,
they
are
going
to
prefer
what
is
at
least
suck
to
develop
and
for
that
having
even
understandable,
yeah
much
better,
but
there's
a
quite
big
difference
in
drum
data.
Just
as
we
need
to
be
minimal.
C
Yeah,
so
the
the
volume
of
the
data
combined
with
being
a
telemetry
library.
We
are
not
the
the
primary
driver
of
value
of
the
of
the
end
users
application.
If
we
affect
their
performance
or
whatever
too
much,
they
are
likely
to
just
remove
us,
which
is
not
what
we
want.
C
That
was
all
I
had
on
the
agenda.
Is
anyone
have
anything
that
they'd
like
to
add
before
we
go
through
and
look
at
bugs,
which
is
everybody's
favorite
thing
to
do.
F
Yeah
I
I
could
probably
just
give
a
quick
update
in
the
sandbox.
It's
still
going,
I've
been
working
on
trying
to
create
a
github
workflow
so
that
it
will
generate
the
the
pr
automatically
do
the
merge.
I'm
having
issues
getting
my
open,
telemetry
bot
working
like
I
can
run
my
script
locally
works
perfect,
run
it
in
github
that
keeps
failing.
So
I
was
working
with
trusk
yesterday
trying
to
figure
out.
Why
don't
know
yet
as
soon
as
I
get
that
going,
then
we'll
we'll
have
a
merging
thing.
F
C
C
I
think
this
may
still
be
a
bug,
but
I'm
not
entirely
sure
the
instrumentation
base
and
the
register
instrumentations
are
both
calling
enable
here.
So,
let's
see
if
this
is
still.
A
The
enable
shoot
the
short
circuit,
if
it's
already
enabled,
though
isn't
it
connected
to
the
issue.
Part-
was
kind
of
trying
to
fix
a
long
time
ago
that
had
to
do
with
the.
A
C
Is
so
if
you,
if
you
call,
let's
see
where
was
he
let's
see,
register
instrumentations,
which
is.
C
Defined
here
it
calls
enable
instrumentations,
which
calls
instrumentation.enable,
but
then
also
the
constructor.
C
Is
also
calling
enabled
is
also
calling
label
so
see.
Look
at
this
everything
is
moved
main
packages
instrumentation.
C
It's
here
yeah,
so
it's
still
called
here,
so
the
constructor
of
the
of
the
instrumentation.
It
actually
enables
itself
when
you
call
so
you
you
inherit
from
this
instrumentation
base,
and
then
you
call
super
when
you
call
super
it
enables
itself,
but
then
the
autoloader
also
enables
it.
So
if
you.
C
C
Yeah,
so
that's
the
thing
this
this
configuration-
this
is
a
bad
name,
and
this
is
this
does
not
mean
it's
already
been
enabled
it's
just
the
configuration.
That's.
It
should
be
enabled.
H
C
I
mean
this
is
still
definitely
a
bug.
I
don't
think
it's
causing
any
actual
problems
right
now,
but
it's.
C
C
C
Okay,
I
mean
this
is
clearly
a
bug.
I
don't
know
how
do
we
want
to
prioritize
this?
I
think
if
it
was,
if
it
was
breaking
a
lot
of
people,
we
would
hear
about
it
more.
I
assume,
maybe
that's
not
a
valid
assumption.
C
C
I
mean
the
the
way
to
solve
this
is
to
probably
add
and
enable
the
flag
on
the
base
class
for
instrumentation,
but
we
don't
yeah
and
then
just
set
it
both
in
the
constructor
and
in
the
register.
Instrumentations
call.
But
if
somebody
else
calls
enable
themselves
that
won't
be
set.
C
I
mean
personally,
I
think,
see:
where
are
we
yeah?
The
instrumentation
package
is
still
experimental,
so
we
can.
I
would
rather
change
the.
C
Autoloader
to
not
accept
like
right
now
it
accepts
this
huge
overload
list
of
of
possible
types.
C
Types,
internal,
this
autoloader
options.
It
allows
an
instrumentation
option
which
can
be
the
constructor
like
the
base
or
array
of
the
base,
which
is
like
the
the
constructor
itself
or
like
it
just
accepts
too
many
things
I
would
rather
have
it
only
accept
an
instrumentation
that
is
already
been
constructed,
so
just
be
instrumentation
like
that
and
not
handle
calling
new
on
it
or
anything
along
those
lines
like
that
can
be
pretty
easily
done
manually.
C
Let's
assign
a
priority
to
this,
so
we
can
move
on,
though,
do
we
think,
let's
see
it's
not
causing
crashes,
it's
not
causing
instrumentation
to
be
incorrect.
I
would
say
this
is
p3
probably
potentially
causes
a
problem
in
the
user
app,
but
is
not
a
crashing
bug
or
anything
like
that.
Everyone,
okay
with
p3.
C
I'm
gonna
take
silence,
for
yes,
is
there
anybody
that
wants
to
handle
this
that
I
can
assign
this
to.
C
B
It
was
a
long
time
ago
and
it
was
like
a
flower.
I
think
I
commented
on
another
pr
that
I
wrote.
I
don't
think
it's
affecting
anyone,
I'm
not
sure
if
it's
even
relevant.
B
I
can
check
it
again
and
I
comment
on
the
issue.
C
246,
which
orientation
doesn't
support
array
headers?
Oh
I
remember
this,
so
this
was
actually
been
fixed
a
while
ago.
I
think
that
this
bug
was
most
likely
fixed
in
that
case,.
C
B
C
Yeah,
I
think
that
this
was
just
a
version
incompatibility,
but
it's
really
old.
I
think
that
this
is
most
likely
was
not
a
bug
at
the
time,
but
is
definitely
not
a
bug
now.
I
think
I'm
just
going
to
mark
this
scale
and
close
it
if
everyone's
okay
with
that.
D
This
other
issue,
where
this
issue
is
mentioned,
says
that
this
might
be
related
and
histogram
max
support
is
now
implemented,
but
I
haven't
really
looked
into
it
further.
Then.
C
G
C
D
C
C
Yeah
I
mean
that
that
makes
sense,
except
that
this
is
our
http
example,
which
is
our
our
example
itself
is
out
of
date.
So
it's
just
it's
like.
If
you
look
at
the
main
branch,
http
package.json
here,
it's
super
out
of
date
and
hasn't
been
updated.
Since
this
issue
is
open,
I
think
in
general
yeah
we
should,
if
someone's
using
old
versions,
we
should
try
to
get
them
to
use
new
versions,
but
in
this
particular
one
I
think
this
example
just
needs
to
be
updated.
C
So
yeah
he
updated
to
newer
versions
and
it
started
working.
I
think
the
example
itself
is
no
longer
using
the
old
api,
so
he
it
was
fixed
when
he
updated.
The
api
did
not
use
the
rc
version.
What
he
said
in
the
issue
here
only
appears
when
using
the
rc
updated
to
those
versions.
C
So
he
used
the
older
api,
but
the
newer
api
would
work
too.
I
remember
the
rc
api
had
a
problem
head
version,
conflict
problems,
so
the
example
needs
to
be
updated,
but
I
think.
C
Okay,
I
think
we've
been
doing
this
for
long
enough
today.
I
will
give
everybody
15
minutes
of
their
time
back,
unless
somebody
has
something
that
they'd
like
to
bring
up
now.
I
I
did
have
a
question:
this
is
jamie
from
honeycomb.
I
think
porvy
and
I
wanted
to
ask
about
last
week
related
to
the
js
contrib
issues
with
releases.
I
think
that
you
would
mention
something
about.
It
was
an
issue
with,
like
getting
rate
limited.
I
think-
and
I
didn't
know
if
that
was
still
an
issue
and
if
it
was
something
I
don't
have
like
any
like
approvals
for
anything
like
that,
but
wondering
if
it
was
like,
is
it
like?
I
We
need
another
level
or
license
for
like
ci
or
for
like
github
or
something
like?
Is
it
like
a
funding
thing
that
if
we
were
able
to
push
for
funding
from
somewhere
to
not
get
rate
limited
like?
Is
that
a
thing
or
a
solution,
or
is
that
unrelated
to
the
issues
we're
having.
C
I
don't
know
the
answer.
I
know
that
we
are
already
on
a
paid
account
of
some
kind,
but
I
don't
know
if
there's
multiple
levels
of
paid
accounts
or
if
you
could
pay
to
have
the
the
rate
limit
increased.
C
I
also
don't
know
whether
it
would
be
like
per
token
or
per
organization
account,
or
anything
like
that.
I
think
a
the
better
solution
would
be
to
update
the
release
automation
so
that
it
doesn't
get
rate
limited
just
to
respect
the
rate
limits
better,
but
I
mean
the
short
answer
is
I
don't
know
I'm
not
familiar
enough
with
github's
pricing
model
and
I
don't.
G
C
What
tier
the
seat,
the
open
telemetry
account
is
on
or
anything
like
that.
I
Okay,
so
right
now
it
regardless
of
potential
tiers
or
licenses
that
may
or
may
not
be
available-
that
we
may
or
may
not
be
on
that's
sort
of
irrelevant,
because
our
goal
is
instead
to
change
the
release
process
anyway,
to
reduce
the
chance
of
the
rate
limit
being
an
issue
and
that's
something
that's
being
worked
on.
C
That's
that's
what
I
think
is
the
better
solution.
I've
opened
issues
with
the
release,
please,
which
is
the
automation
that
we
use
to
see
if
there's
ways
to
to
respect
rate
limits
better
other
users
have
run
into
similar
things,
and
I
have
not
gotten
a
lot
of
response
from
them,
which
is
unfortunate.
G
C
Just
released
a
new
version
of
the
sdk,
we
have
to
update
all
the
contrib
packages
to
use
the
new
sdk
and
when
that
pr
gets
merged
and
released,
every
single
package
needs
to
be
updated,
which
is
just
too
many
to
do
all
at
once,
and
we
run
into
the
rate
limit.
So
the
the
work
around
solution
is
that
I
release
those
manually
right
now,
but
a
better
long-term
solution
would
be
to
have
the
release.
C
Automation,
respect
the
rate
limit,
but
I
think
currently
there's
no
there's
no
good
proposals
for
how
we
should
do
that.
It's
that's
the
goal.
We
just
don't
know
how
to
do
it
gotcha
if
we
could
increase
the
rate
limit,
it
obviously
solves
the
short-term
problem,
but
I
don't
know
if
that's
even
an
option.
C
Now
I
can
ask
I
can
try
to
find
out
what
what
tier
we're
on
and
whether
that
can
be
whether
the
rate
limit
can
be
raised.
I
It
might
be
worth
finding
out
and
then
we
can
say
like
okay,
here's
our
options
of
different
things,
because
obviously
it's
not
ideal
long-term
for
you
either
right
to
have
to
release
these
manually
and
if
we're
not
sure
yet
how
to
make
that
better.
And
it
might
be
like
oh
nothing
we
can
do
or
the
price
is
something
that
someone
doesn't
want
to
pay
or
you
know
whatever
it
may
be.
But
maybe
it
doesn't
hurt
to
find
out.
If
that's
one
of
the
options
available.
C
Yeah,
that's
reasonable,
so
let
me
look
into.
C
I
will
look
into
that
because
yeah
I
can
talk
to
our
cncf
contact,
who
deals
with
paying
for
our
github
account
and
and
see
what
the
options
are
there.
C
Okay,
well
give
everybody
10
minutes
back,
enjoy
the
rest
of
your
day,
and
I
will
talk
to
you
in
a
week.