►
From YouTube: 2022-07-07 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
I'm
not
ignoring
this
one.
I
just
need
to
have
some
time
to
remember
what
I
I
can
never
remember
how
the
reference
queue
stuff
works,
so
I
just
like
keep
kicking
it
down,
but
I
I
promise
we'll
review
it
before
the
really.
B
Yeah
take
all
the
time
you
need
like.
I
definitely
need
some
shared
responsibility.
C
A
I
wanted
let's
see
thank
you
mateish
for
taking
a
initial
look
at
this,
not
sure
if
you
had
a
chance
to
look
today.
Okay,.
D
A
B
A
From
you,
given
that
it's
still
I
mean
it's
still
a
ways
off
from
actually
landy
and
I
just
wanted
to
prototype
yeah
the
spec
for
this.
A
Yeah,
I
think
I'm
good
here.
Yes,
I
think
I'm
good
and
I
can
I
just
want
ludmila's
blessing,
and
then
I
will
approve
that
spec
pr,
based
on
and
post
that
we've
prototyped
it.
D
Yes,
I've
been
doing
even
some
more
work
about
this.
I
merged
the
first
config
properties.
Pr
today,
if
I
remember
correctly,
it
was
about
the
agent
listener
and
not
using
config
there,
because
it
seems
to
me
that
the
current
direction
we
want
to
go
into
is
using
config
properties
everywhere,
in
extension,
api,
so
that
our
sdis
are
kind
of
matching
the
sdks
spi
sdk,
auto
configures,
pis
and
everywhere
else.
We
will.
D
We
are
going
to
deprecate
the
existing
config
class
and
instead
introduce
a
new
instrumentation
config
one,
that's
agent,
only
and
internal
at
least
now,
and
make
all
library,
instrumentations
and
instrumentation
api
called
a
library
called
basically
just
use
programmatic
configuration
without
any
any
sort
of
configuration.
D
So
yeah
I've
been
following
these
two
threats
in
separate
series
of
prs
that
are,
that
will
probably
be
merged
at
some
point
and
my
most
recent
thing
that
I
discovered
and
discovered
the
role
I
formed
an
opinion
about
this
today
is
that
I
believe
that
we
should
build
the
config
property
config
properties
instance
in
the
agent,
not
in
the
sdk,
and
there
are
several
reasons
why
we
would
probably
prefer
doing
that
but
yeah.
I
I
think
we.
D
A
But
don't
we
we
still
call,
we
still
do
this
right
and
we
instantiate
the
auto
configured
sdk.
We
don't.
D
If
we
are
running
using
the
no
api
mode,
then
we
don't
even
get
to
the
point
when
we
initialize.
A
D
So
that's
that's
one
thing.
The
other
thing
is
that
the
instrumentation
config
it's
also
kind
of
like
a
bridge
over
to
their
computer
properties.
So
if
we
don't
have
config
properties,
then
we
don't
have
any
config
and
the
third
part,
that's
probably
the
splunk
full
scale
about
this.
The
most
is
the
customized
api
of
the
config
customizer.
D
D
A
D
Yeah
they're
kind
of
the
same,
but
you
know
they
manifest
in
different
ways
like
the
first
one
is
visible
in
instrumentation
modules.
When
they,
you
know
you
can
even
turn
it
on
or
off,
and
the
second
one
is
more
like
within
the
within
the
advice
code,
when
the
helper
classes
themselves
so
yeah,
it's
the
same
problem,
that's
correct.
A
A
Okay,
yeah,
we
don't.
E
A
The
sdk
folks,
so
I
will
carry
that
forward
this
evening
and
and
see
if
we
can
thank
you,
get
some
resolution
yeah
yeah.
That
makes
a
lot
of
sense
to
me,
though,
if
there's
a
way
to
make
that
happen,.
A
Yes,
I
wanted
to
ask
for
another
set
of
eyes
on
the
new
runtime
attach
changes,
so
the
the
main
change
here
is
bundling
the
java,
I
think,
before
we
had
the
java
agent
as
a
transitive
dependency
of
the
runtime
attach
module
and
the
problem
that
we
were
seeing
with.
That
is
when
we
add
that
that
the
java
agent
is
then
on
the
class
path,
plus
we
use
it
to
attach
the
java
agent.
C
C
A
Agent,
so
the
bite
buddy
attach
is
that
is
specifically
designed
for
attaching
an
external
jar.
That's
not.
C
C
A
Any
other
sort
of
who
yeah
so
and
I
was
curious.
I
know
nikita
had
originally
been
interested
in
this
project.
Do
you
know
if
you
have
splunk
users
using
this.
D
No
idea
honesty,
at
least
I
I
can't
remember
any
now.
Maybe
nikita
knows
somebody
we
must
have
had
some
at
some
point.
I
suppose.
A
Cool
yeah,
whenever
maybe,
if
you
or
laurie,
have
a
chance
to
just
give
it
a
I've,
I'm
pretty
much
done
with
pretty
much
approving
it
with.
I
think
I
had
one
sort
of,
and
it
looks
like
you
are.
A
Oh,
I
guess
so.
My
question
here
john
was
before
this
pr.
It
would
create
a
new
temp
file
and
write
the
java
agent
to
that
and
now
it
creates
a
new
temp
folder
and
writes
the
javascript.
E
A
Yes,
I
also
wanted
to
get
eyes
on
this
proposal.
A
A
You
know
kind
of
just
moving
forward
with
yaml
for
like
the
metric
views
and
for
now
we
can
just
have
it
an
external
config
file
that
we
have
a
property
that
points
to
it
and
then
at
some
some
point
we
can
unify
at
all.
A
So
just
with,
since
it's
a
decent
amount
of
work
that
it
sounds
like
the
app
dynamics.
Folks,
I
think
have
dynamics
folks
are
sound
interested
in
taking
on
it
would
be
good.
To
have
sort
of
blessing
of
this
is
something
we
would
take
in.
A
I
think
it's
a
great
feature.
I
think
it's
a
missing
been
a
significant
missing
feature
in
the
java
agent
to
collect
arbitrary
gmx
metrics.
E
A
So,
ideally,
I
think
we
would
want
both
library
instrumentation
and
then
a
java
agent
instrumentation
that
basically
injects
that
library
instrumentation
so
that
it
can
be
used
both
with
the
java
agent
or
without
the
java
agent.
D
D
Or
rather
that's
one
option
or
the
other
option
is
scraping,
but
instead
of
using
some
custom
groovy
code,
just
using
the
library
instrumentation
to
listen
on
a
remote
and
bing
server.
A
Oh,
I
understand
what
you're
saying
right,
because
the
same
library
code
should
work
on
the
local
platform
and
being
as
for
a
remote,
oh
interesting,.
E
And
my
question:
it
was
almost
like
if
it
fits
in
the
the
open
telemetry
java
project
or
if
it's
open,
telemetry's
instrument,
java
instrumentation
project,
like
one
I'm
wondering
if
like
if
it's
part
of
the
java
one
and
basically
what
the
instrumentation
is
you.
It
contains
a
a
set
of
jmx
configs
that
ships
with
it
that
gets
picked
up
if
they
match
like
they've.
So
someone
was
working
on
building
the
kafka
one,
so
it
could
be
like
here.
E
Okay,
here's
the
configuration,
here's,
the
zookeep
cooperation
and,
if
you
put
in
the
agent
they
will
sort
of
recognize
okay
yeah.
I
have
these
jmx
beans,
so
I
should
be
picking
them
up
because
I
have
the
configuration
and
it
becomes
more
sort
of
similar
to
what
the
like
bytecode
instrumentation.
It
sort
of
automatic
j
mix
beams
getting
picked
up.
A
Yeah,
so
we
have
a
couple
that
are
similar
to
this,
so
like
runtime
metrics
are
so
we
split
out
into
oh.
I
went
into
the
java
agent.
I
wanted
to
go
into
library,
so
this
is
as
sort
of
something
you
can
use
as
a
normal
dependency
pull
into
your
code
and
it
will
emit
kind
of
some
standard
jvm
level.
A
I
think
all
of
these
are
based
on
mx,
b
and
beans,
so
in
our
kind
of
currently
I
think
it
fits
in
the
instrumentation
repo.
A
One
of
the
things
we've
been
using
to
decide
which
repo
it
fits
in
is
if
it's
like
a
specked
component,
open,
telemetry,
spec
component,
then
it
lives
in
the
core
repo,
although
we
actually
it
have
a
bunch
of
things,
sort
of
that
we're
sort
of
grandfathered
in
here
that
we're
thinking
of
moving
over
to
maybe
contrib
repo,
even.
A
E
E
Cool,
no,
it's
just
one
of
those
things
I
would
like
to
think
about
is
sort
of
some
of
these
standardized
metrics
as
the
ones
you
show
theirs,
sort
of
cpu
and
whatnot.
You
want
them,
I'm
more
from
a
user
perspective
like
I
want.
I
was
like
teaching
the
developers
in
the
organization
like
okay,
we
want
to
use
open
telemetry
and
you
can
use
the
apm.
We
recommend
to
use
that
and
you
can
use
sort
of
sort
of
manual
instrumentation
as
well.
E
If
you
want
but
sort
of
the
standard,
jvm
metrics,
we
want
to
be
always
the
same
right.
So
this
is
one
of
those
things
where
like.
If
you
pick
up
just
the
java
api,
you
would
get
those
other
books
but,
like
I
guess
you
would
add
the
job
api
and
and
then
you
would
take
this
extra
library
and
then
that
would
be
sort
of
the
way
to
get
it.
So
it
might
be
good.
I
gave
yeah
so
with
that
in
mind,
like
yeah
at
least
for
start
putting
it
as
a
library.
A
Yeah,
even
if
it
lived
over
here,
I
know
that
they
wouldn't
want
to
include
it
like
directly
in
the
api
package.
Yeah
it
would
be,
and-
and
it
could
like,
I
could
see
it
being
kind
of
like
micrometer
shim,
almost
like
it's
a
jmx
shim.
A
So
there's
there's
actually
an
interesting
dmx.
A
I'll
ask
the
sdk
the
core
so
that
then
we
don't
have
any
of
the
maintainers
right
now
from
the
core
repo,
but
we
have
another
meeting
with
them
in
the
evening
that
actually
all
three
of
them
generally
join.
So
I
will
throw
that
at
them
see
what
their
reaction
is.
E
A
Cool
and
then
you
had
a
oh.
E
Yeah,
so
so
I
it's
probably
two
years
ago
since
I
joined
the
meetings
sort
of
some
somewhat
familiar
but
yeah
nice
to
see
you
yeah,
taking
in
different
directions.
I
haven't
had
much
time,
but
now
I'm
gonna
start
picking
up
more
open
temperatures
so
trying
to
get
stuff
looking
at
getting
back
into
how
things
work
and
and
whatnot.
E
But
one
one
thing:
that's
come
up
on
our
end
is
sort
of
having
some
off
capabilities,
because
we
want
to
capture
metrics
and
sort
of
externally
and
get
them
back
in
in-house
to
our
end,
and
so
so
we'll
need
some
sort
of
authentication
as
part
of
that
and
and
the
open
telemetry
collector
supports
sort
of
oauth,
and
then
you
can
run
the
open
id
connect
stuff
on
the
back
end
and
then
be
able
to
get
that
to
work.
E
It
would
be
interesting
to
do
that
on
the
java
side
as
well,
and
then
sort
of
it
seems
like
oh
yeah.
One
way
of
doing
it
is
sort
of
okay.
I
could
create
my
own
span.
Exporter
load
it
in
as
sort
of
an
extension,
but
I
want
to
send
open
otlp
http
request
right.
I
want
to
re-implement
that
whole
class
and
what
happens
is
okay.
E
I
need
to
add
this
authorization
bearer
and
token
into
that
header,
but
the
way
it
works
today
is
I
create
my
the
builder
I
set
like
add
this
header,
and
then
I
build
the
exporter
so
for
update
header.
I
have
to
recreate
the
whole
exporter,
even
though
the
headers
are
on
the
request
level
and
okay
http.
E
So
it
would
be
interesting
and
sort
of
just
on
top
of
my
head,
like
I
could
figure
out
two
things
like
either
it
might
be
interesting.
Should
we
have
sort
of
some
author
authentication
extension
that
it
was
just
scanning
a
little
bit.
It
looked
like
okay,
http,
3
or
ok.
Three,
I
forget
where,
where
the
three
comes
in
the
hp,
library's
name,
but
they
had
some
authentication
extension,
we
probably
don't
want
to
expose
that
one
into
open
telemetry,
but
perhaps
with
limiter
you
could
have
its
own
wrapper
around
it.
E
That
could
be
more
generic
or
should
we
support
some
type
of
I
can
give
a
lambda
as
a
header
provider,
and
then
that
is
sort
of
a
basic
way
of
doing
it.
At
least
supporting
that
it
might
not
be
all
the
authentic
what
the
authentication
libraries
need.
They
might
need
to
do
other
thing
than
just
adding
a
single
header
right
and
but
I've
been
interested
to
see
sort
of
what,
for
now,
at
least
for
my
testing
I'll,
just
sort
of
recreate
this.
E
Whenever
the
the
token
expires-
and
I
can
do
my
testing-
and
it
probably
will
work
in
production
even
like
as
long
as
you're-
not
invalidating
every
five
minutes.
But
if
it's
like
an
hour
or
two,
it's
probably
fine
for
a
while.
But
I'm
interested
to
sort
of
see
like
okay,
what
what
extension
would
be
feasible
to
do
sort
of
in
the
instrumentation
level,
slash
open
symmetry
java,
which
might
be
where
it
needs
to
fit
in.
A
Yeah,
I
would
recommend
opening
an
issue
over
here
in
the
core
repo
because
it
affects
the
sdk.
The
sdk
exporters,
and
I
know
that
sort
of
the
one
like
potentially
adding
a
hook
to
expose
like
a
lambda
is
something
that
they
might
consider.
A
Adding.
Native
oauth
support
is
something
that
they
would
probably
consider,
but
only
after
adding
that
to
the
spec
like.
If
so,
if
you
want
that
would
oh
do.
We
have
maybe
there's
even
a
let's
just
check
if
there's
so.
E
So
one
interesting
aspect
is
the
capability
like
the
the
way
it
supports
in
in
in
the
collector.
Is
that
in
the
collector
you
can
say
like
okay,
I
want
you
to
send
otlp
over
http,
for
example,
and
then
you
have
an
authentication
section,
so
there
is
like
in
the
collector.
There
is
sort
of
everything
that
exports-
or
I
don't
know
everything,
but
a
lot
of
the
things
that
concerns
exporting
or
sending
something
over
the
wire
has
sort
of
an
authentication
section
to
it.
E
Where
sort
of
you,
you
write,
you
have
an
extension
that
you,
you
configure
and
your
extension
might
be
off
or
open
id
connect
or
whichever
authentication.
So
you
have
an
api
for
that,
and
then
you
just
say
like
use
this
and
as
your
callback
for
authentication.
So
so
that
x
is
there.
So
that
might
be
sort
of
the
way
to
think
about
it.
Here
is
sort
of
okay.
How
do
I
add
sort
of
an
authentication
api
as
part
of
any
exporter?
If
you
wanted
to.
A
Yeah
yeah,
I
think
that
sounds
like
a
good
proposal.
I
think
the
oauth
built-in
oas
support
sounds
like
it
could
be.
You
know
useful
for
other
people,
but
that
would,
I
think,
need
to
be
driven
through
the
specification.
First.
A
Yeah
and
I'll
I'll
we're
in
the
evening
meeting,
we
review
the
notes
from
the
morning,
so
I'll
kind
of
give
them
a
heads
up
on
that
and
the
immediate
the
evening
meeting
is
is
open
if
you
yeah
it's
at
six
specific
depending
on
your
time
zone
or
whether
yeah.
A
Cool
that
was
our
gender
always
skipped
over
this
from,
I
believe
the
sdk
is
gonna
release.
Normally
it
would
be
this
week
and
so
instrumentation
would
be
next
week.
A
A
D
Yeah,
I
think
we
could
do
that.
I
mean
the
instrumentation
api
is
probably
quite
finished.
Quite
stabilized
I
mean
the
config
was
the
very
last
thing
that
we
wanted
to
fix,
or
you
know
settle
before
we
mark
this
in
rc
and
there's
yeah.
There's
the
failed,
build
binary
company
phase,
but
yeah.
That's,
I
think,
that's
just
introducing
the
j
api
desk.
D
I
have
one
topic
that
just
I
just
came
up
with
today,
because
I
noticed
I've
learned
recently
that
the
spring
starter
is
apparently
being
used
inside
slang.
So
maybe
you
remember
the
pr
jason
created
that
fixed
the
spi
dependency.
So
I
thought
that
maybe
we
should
make
it
at
least
not
terrible
and
kind
of
decent.
D
So
while
I
I
was
working
on
a
few
things
like
adding
metrics
that
I
come
up
with
an
idea
that
maybe
we
could
move
the
the
spring
auto
configure
and
the
spring
starters
into
the
country,
because
it's
not
really
I
connected
with
java
agent.
I
wouldn't
even
call
it
an
instrumentation
library,
because
it's
not
it's
like
the
alternative
to
in
java.
D
D
Yeah
spring-
and
there
is
spring
auto
configure-
is
the
like
the
actual
code
and
the
starters
folder.
At
the
end,
it's
kind
of
the
distribution
I
mean
there
is
no
java
code
here,
but
the
each
of
these
starters
just
packages
dependencies
together.
A
So
I
definitely
agree
that
it
doesn't
belong
under
this
folder
yeah.
It's
not
instrumentation,
so
whether
it
you
know,
gets
its
own
top
level
component
here
or
in
contrib.
A
Yeah,
thank
you
for
paying
some
attention
to
these,
though,
because
they
have
been
long,
neglected
and
people
love
spring
boot
starters.
So
it's
it's.
D
Kind
of
yeah,
I'm
kind
of
surprised
how
many
people
are
using
it.
I
mean
you
would
kind
of
think
that
the
spring
sleuth
is
the
main
solution
for
this,
but
that
there
are
apparently
people
that
use
our
starters
yeah,
even
though
they
look
like
like
they
look
currently
and
they're,
even
missing
the
basic
cross-thread
context
for
propagation
right.
So
that's
another
thing
that
I
learned
very
recently,
because
some
user
posted
an
issue
about
that.
D
A
Yeah,
let
me
see
what
other
folks
think
like
we
have
been
hesitant
because
of
spring
cloud
sleuth.
A
D
Yeah-
and
I
mean
the
spring
cloud
stuff
is
a
kind
of
even
more
reason
to
move
it
into
country,
because
it's
it's,
then
you
know
just
just
another
country
project
that
might
be
dropped
if
we
decide
to
do
so
and
another
part
of
the
agent.
So
I
I
think
it
makes
the
distinction
between
the
instrumentation
libraries
and
the
instrumentation
agent
and
the
the
starter
project
like
more
clear.
E
A
Yeah
there's
some
interesting
stuff
over
here,
yeah
for
definitely
like
the
this.
One
is
fairly
heavily
used
right
now
by
some
vendors
and
a
lot
of
users,
but
was
what
mateish
was
referencing
about
the
jmx
if
we
am
potentially
being
able
to
replace
this,
if
we
have
a
jmx
library
scraper
or
rebuild
this
with
that
piece,
this
consistent
sampling
has
a
rate
limited
rate
limiting
sampler,
which
is
really
nice.
I
think
very
useful.
A
Runtime
attach
we're
talking
about
earlier
and
the
static
instrumenter
is
still
a
work
in
progress,
but
very
promising
project
to
be
able
to
statically
instrument
at
build
time,
as
opposed
to
via
runtime
java
agent,
which
could
help
with
startup
times
and
also
help
with
crawl
bm
support.
E
E
We
would
talk
about
like
I
know.
The
open
telemetry
operator,
for
example,
has
the
the
injector
pattern
supports
that?
But
it's
sort
of
been
we've
been
debating
a
little
bit
back
and
forth
like
do
you
want
to
do
that
or
how
does
it
flow
through
testing?
Because
then
you
sort
of
might
not
go
through
the
whole
testing
phase
of
an
application
when
you're
you're
updating
just
injectors.
A
Yeah
this,
this
is
another
option
for
solving
that
problem
if
you
are
using
spring
boot
or
if
you're,
using
anything
where
you
have
are
able
to
write
some
code
in
the
actual
main
method,
you
can
add
this
as
a
dependency
and
attach
at
that
point,
and
then
it
gets
bundled
up
into
your.
You
know.
A
Yeah,
so
we
generally
at
the
beginning
of
the
month,
first
week
of
the
month,
first
or
second
week
of
the
month,
we
released
the
core
repo
and
then
instrumentation
repo
after
that
and
then
contrib
repo.
After
that.