►
From YouTube: 2022-09-01 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
B
A
A
Yeah,
it
shouldn't
be
the
lorry
from
the
founder,
pretty
good
thing
that
I
like
completely
overlooked
and
didn't
think
about
it.
So
I
should
probably
revoke
an
approval
if
I
knew
how
but
yeah
it
still
needs
to
get
some
more
fixes.
B
Check:
okay,
cool.
A
Yeah
I
reviewed
this
one
yesterday,
I
think
the
user
who
contributed
introduced
the
library
instrumentation
and
like
that,
there's
usual
things
that
we
want
to.
We
want,
like
various
limitations,
to
have
and
conform
to.
So
it's
like
lots
of.
A
That
one's
interesting,
I
finally
managed
to
make
it
work
with
sf4j2,
but
I
did
not
update
the
general
sl4j
version
in
the
dependency
management
module.
I
just
updated
the
version
that's
used
inside
the
java
agent
bootstrap,
so
it's
we're
actually
using
the
2.0
inside
the
java
agent,
but
like
everywhere,
in
tests
and
yeah
and
like
everywhere,
in
tests
we're
still
using
one
point,
something
because
that's
the
version
that
is
used
by
everything
that
is
currently
like
used
everywhere.
So
we
can't
really
bump
it
so
yeah.
B
A
I
was
thinking
of
also
maybe
improving
the
vlogging
story
a
little
bit
or
like
encapsulating
and
hiding
the
actual
login
library
a
bit
better.
But
I
will
try
to
something
desperate
here
for
that,
because
right
now
we
will
still
have
slf4j
in
the
goodstar
class
loader
and
it's
still,
for
example,
visible
in
the
shading
gurus.
But
I
think
we
could
probably
introduce
some
another
internal
internal
layer
of
abstraction
that
will
be
used
by
patch
logger.
A
B
A
Better
but
yeah,
that's
a
separate
change.
I'll!
Try
to
make
the
pr
next
week,
probably
and
we'll
see
if
it
catches
on.
A
A
B
D
A
Yeah,
but
I
think
that
microsoft
destroys
like
using
the
lockback
for,
like
actual.
B
D
E
A
B
Yeah
I
mean
I
kind
of
like
having
the
separate
agent
log
from
support
like
I
can
just
ask
it's
easy
to
ask
support
for
get
me
turn
on
this
option.
Get
me
this
log
and
I
don't
have
to
worry
about
where
the
customers
logs
are
going,
but
there's
also
for
sure
advantages
to
going
to
the
customers
logs
also.
C
As
always,
always
good
things
to
chat
about,
go
for
it
all
right,
so
the
first
one,
so
we've
moved
a
couple
of
components
to
contrib
the
no
op
api
and
jfr
events,
and
those
are
both.
They
both
are
alpha
artifacts
and
I'm
curious.
What
folks
think
about
you
know?
C
I
I
charged
ahead
and
didn't
add
a
deprecation
cycle
to
this,
and
I'm
okay
with
that,
because
they're
they're
alpha
artifacts
and
I
don't
have
data
to
support
this,
but
you
know,
I
suspect
that
they
aren't
super
heavily
used,
so
that's
kind
of
influencing
that
decision
a
bit,
but
I
wanted
to
know
what
other
people
think
was.
I
jumping
the
gun
by
not
replicating
these
first
before
deleting
them
all
together.
E
I
don't
think
it's
necessarily
a
problem
as
long
as
we
call
it
out
super
clearly
in
the
in
the
release
notes,
so
onorag
originally
wrote
the
full
no
op
api.
So
I
wonder
whether
this
is
something
that
amazon
is
using.
B
We
were
originally,
but
then
we
replaced
it
with
the
the
now
that
the
sdk
is
more
than
one
okay,
enabled.
A
E
E
E
C
I
think
we
have
three
degrees
of
no
ops.
We
have
this
no
op
api
that
we're
talking
about,
which
is
absolutely
no
op.
No
contacts,
pr
property,
no
contact
storage,
even
like
even
the
contact
storage
mechanism,
is,
is
no
up,
and
then
we
have
the
you
know
the
no
op
implementation
that's
available
through
the
api.
So
if
you
say
like
what
is
it
tracer
provider
dot?
No
op,
you
get
a
different
version
of
a
noaa
tracer.
C
E
I
can
look
that
up
real
quick
yeah.
I
don't
remember.
I
didn't
look
at
the
code.
It's
been
a
while,
since
I
dug
into
that
particular
tangle.
C
B
And
it
reads:
oh
tracer
provider
is
different
from
the
context
propagator
anyway.
So
great.
E
But
yeah
and
it
will
propagate
that
no
opting
will
propagate
trace
ids
through
the
system
yeah.
You
could
use
that,
but
have
propagators
configured
so
that
you
could
have
a
pass
through.
C
So
so
this
affects
the
opto
configuration
builder
right.
E
E
Yeah
that
true,
full
no
op
was
not
used
by
auto
configuration.
D
C
And
the
reason
is
is
because
the
way
that
it
gets,
you
know
it's
turned
on
it's
like
an
spi
mechanism
and
it's
activated
as
soon
as
it's
on
the
class
path.
And
so
if
you
include
that
in
your
project
it
will
be
turned
on,
and
so
you
can
accidentally
really
easily
accidentally
turn
off
contact
storage
with
this
artifact.
E
Yeah
exactly
so,
you
have
to
propagate
context
if
you're
using
the
normal,
just
the
api
and
if
I
recall
the
purpose
of
this
no
app
api,
the
full
no
op
api
was
performance
testing
of
instrumentation
to
see
if
you
could
isolate
just
what
is
the
overhead
of
the
instrumentation
itself
without
any
sdk
or
api
actual
doing
anything
at
all.
So
you
could
see
whether
your
instrumentation
was
generating
a
lot
of
garbage,
etc.
E
E
Moved
yeah,
the
question
jack's
question
was
really:
is
it
okay
that
we
just
deleted
it
rather
than
going
through
a
deprecation
cycle,
and
I
think
it's
fine?
I
think
the
usage
of
this
would
be.
It
would
be
very,
very
narrow
usage
and
that
people
who
would
be
using
it
would
be
deeply
involved
and
understand
what
was
going
on.
So
it
wouldn't
be
a
big
deal
for
them
to
pull
in
the
new
artifact.
C
Yeah
and
in
general
I
was
just
thinking
about
like
philosophy
and
moving
alpha
artifacts
in
general,
and
you
know,
switching
the
artifact
coordinates,
isn't
a
big
lift,
so
you
know
you
just
switch
from.
I
o
dot
open
telemetry
to
I
o
open
telemetry.contrib,
so
you
switch
your
artifact
coordinates
and
then
also
the
package
changes.
But
everything
else
is
the
same.
So
I
don't
think
we're
asking
a
huge
amount
from
users
to
to
switch.
E
D
We
anticipate
any
challenges
for
users
if
we
go
the
opposite
route
like
let's
say,
and
I'm
kind
of
speculating
here
but
like
if
somebody
has
a
like
a
whiz-bang
feature,
they
add
to
contrib
and
it
sits
there
kind
of
percolating
for
a
while,
and
then
we
decide
that's
really
cool.
We
want
that
in
the
instrumentation
agent.
D
We
want
to
bring
it
in
right
because
contrib
is
kind
of
like
I
don't
know.
I
could
see
it
as
a
place
where
people
are
trying
some
big
ideas
or
some
new
ideas,
and
then
we
want
to
eventually
bring
that
stuff
in
or
parts
of
it
in
so
when
the
coordinates
change,
then,
is
that
a
problem
I
mean,
I
think,
probably
not
I'm
just
wondering
if
there's
any
concerns.
E
A
A
C
And
so
just
really
quickly,
the
third
version
of
the
no
op
api
is
is
what's
used.
When
you
use
auto,
configure
and
set
you
know,
hotel
experimental
sdk
enabled
equals
false,
that's
the
new
property
we
provided,
and
this
just
uses
an
empty
version
of
an
sdk
tracer
provider,
and
so
you
know,
contacts
will
be
propagated
span.
E
E
E
B
E
C
Maybe
I
don't
know,
I'm
not
sure
if
I
remember
the
that
conversation
exactly
we,
but
just
thinking
out
loud
here.
So
we
could,
just
when
sdk
enabled
is
false.
We
could
just
specify
as
id
generator
implementation
that
generates
invalid
ids,
always
right.
E
B
Too
far
into
the
weeds
yeah,
I
don't
think
this
is
that
important,
but.
C
So
probably
good
to
just
keep
the
behavior,
as
is
for
now,
wait
for
feedback
and
then
try
to
figure
out
and
when
that
feedback
arises.
What
exactly
the
behavior
we'd
like
to
see
is
when
sdks
is
disabled
and
how
that
differentiate
is
differentiated
from
just
a
no-op
tracer
provider,
and
then
we
can
go
from
there.
B
E
C
All
right
yeah
that
pr
is,
I
don't
know
it's
one
month
already,
this
being
discussed.
E
E
E
B
You're
same
for
these
right,
we're
all
good
with
I'm
all
good
with
just
like
john
said
it
to
me.
It's
just
the
release
notes,
because,
even
even
during
the
deprecation
cycle
that
sort
of
relies
on
people
updating
their
artifacts
every
month
anyway,
which
is
not
always
the
case.
So
to
me
that
the
release
notes
are
the
key
okay.
C
Okay,
next
item
this
one's
a
bit
of
a
doozy
okay,
so
we
went
ahead
and
we
added
dependencies
from
our
stable
sdk,
all
component
onto
unstable,
logger
components
and
so
names
of
logger
log
classes,
like
you
know,
currently,
log
emitter
and
log
emitter
provider.
C
You
know
those
were
always
experimental
and
they
weren't
stable
on
the
specification,
and
yet
we
had
dependencies
on
those
from
stable
artifacts
and
the
way
we
justified
this
was
we
said
that
that
the
dependency
that
the
sdk
takes
on
the
log
sdk
is
a
an
implementation
dependency.
And
so,
if
you
want
to
actually
use
that
portion
of
the
api,
you
have
to
add
an
ap.
You
have
to
add
an
implementation
dependency
on
this.
This
unstable
blog,
sdk,
artifact
yourself
and
somewhat
predictably.
C
They,
the
specification,
has
changed
what
the
names
of
these
components
are
so
they're,
no
longer
a
log,
emitter
and
log
emitter
provider,
their
logger
and
logger
provider,
and
so
the
apis
of
our
stable
artifacts
change
somewhat
and
so
obviously,
jpi
compare
does
not
like
this.
It's
it's
a
breaking
change
and
this
pr
that
I've
linked
to
makes
that
breaking
change,
but
basically
suppresses
jpi.
C
Cmp
jappy,
you
know
it
has
a
basically
an
exception
in
there
where
if
this
specific
part
of
the
api
has
changed,
then
it's
it's
a
it's.
An
allowable
change.
C
And
I
wanted
to
talk
about
this
because
it's
it's
an
uncomfortable
thing
to
do,
but
I
do
think
we
have
to
do
it
at
some
point.
C
So
log
emitter
provider,
because
there
wasn't
the
difference
between
the
api
and
the
sdk
yet
and
the
log
in
the
log
world,
you
know
there's
only
an
sdk
log
emitter
provider,
which
is
just
a
class.
It
doesn't
implement
anything
because
you
know
there
wasn't
anything
for
it
to
implement
yet,
and
I
guess
either
way
like
the
open,
telemetry
sdk
class,
where
these
the
contract
is
changing.
You
know
those
accept
the
sdk,
concrete
class
versions
of
the
provider.
So
you
know
when
you
set
the
meter
provider,
it
accepts
a
sdk
meter
provider.
E
B
This
reasoning
that
I
mean
we
knew
what
we
were
doing
at
the
time
of
pulling
in
alpha
artifacts
as
implementation
dependencies,
and
I
thought
we
were
all
comfortable
with
that
and
knowing
that
those
were
alpha
artifacts
and
could
change.
E
E
B
B
B
E
E
E
If
it
is
something
we
all
agree
is
the
right
way
to
go
and
yeah.
I
agree
that
if
you,
if
you
have
decided
to
pull
in
an
implementation
detail
of
your
own
on
an
alpha
alpha
artifact,
you
can
expect
things
to
break.
A
B
B
And
I
wouldn't
want
to
I
didn't.
I
probably
would
have
argued
against
doing
that
if
it
had
meant
keeping
around
some
old
craft
for
backward
compatibility.
C
Yeah,
I
agree,
I
think
it
helped
us
do
more
things
with
the
spis
and
make
auto
configure
more
useful
earlier
on
for
for
logging,
and
it
helped
us.
You
know,
incorporate
that
into
the
open,
telemetry
sdk
object,
and
so
we
got
some
good
feedback
and
were
able
to
get
like
open,
telemetry
logs
into
people's
hands
earlier,
and
so
that
had
good
utility,
and
I
think
I
I
I
I
I'm
with
trask-
I
I
think
I
probably
I
value
that
utility,
but
I
wouldn't
have.
C
I
wouldn't
have
gone
down
this
route
if
we
wouldn't
have
the
ability
to
change
these
classes,
so
we
all
agree.
I
can
update
the
the
versioning
guarantees.
I
can
add
some
more
information
about
that,
and
maybe
we
wait
till
next
release
to
do
this.
Just
so
so.
E
I
guess
one
question
I
have,
which
is
more
of
a
practical
question
rather
than
a
than
a
question
of
principle.
That
is.
Does
this
introduce
any
issues
with
someone?
I
guess
some,
if
they're
using
the
agent
they
shouldn't
be
pulling
in
the
sdk
in
the
first
place
right
like
if
someone
has
a
sdk
on
their
class
path
and
they're
using
the
agent?
E
Yeah,
I
know
I'm
just
wondering
if
someone
did
have
a
dependency
in
the
sdk
incorrectly
have
a
dependency
in
the
sdk,
or
they
did
because
they
sometimes
run
in
agent
mode
and
sometimes
don't
run
in
agent
mode.
So
they
need
to
have
an
sdk
around
just
wanted
to
make
sure
that
wasn't
going
to
potentially
be
a
breaking
use
case
for
them.
E
C
They
yeah,
so
they
don't.
They
don't
manifest
on
the
like.
The
open,
telemetry
sdk
extends
open,
telemetry
or
implements
it,
but
it
adds
these
extra
methods
which
don't
exist
there
right.
B
Oh,
I
see
yeah,
so
we
don't
bridge.
I
don't
think
we
bridge
do
anything
with
open
telemetry
sdk.
I
think
only
the
open,
telemetry
api
class.
C
And
it's
it's
obfuscated
in
a
way
where
it's
really
hard
to
access
the
sdk.
E
C
All
right,
so
I'm
going
to
take
an
action
item
and
honestly,
I'm
going
to
wait
on
this
too,
because
I
want
I.
I
think
I
want
the
the
specification
to
make
some
do
some
more
alignment
between
the
api
and
the
sdk
so
that
we
can
kind
of
become
more
committed
to
this
new
naming
convention
before
I
go
make
this
change
because
I
definitely
don't
want
to
like
revert
again
like
I
don't
want
to
do
this
more
than
than
once.
Hopefully,.
C
Yeah
and
just
some
like
just
commentary
on
this
in
general,
so
it's
pretty
painful
to
update
jpi
to
like
basically
squash
this
and
to
allow
this,
and
so
I
think
that's
like
appropriate
right.
So
if,
if
we
allow
ourselves
to
make
these
changes,
then
it
should
be
painful
for
us
to
do
it
so
that
we're
not
encouraged
to
do
it.
A
lot.
C
Okay,
fair!
That's
what
what
happens
all
right!
Last
item
that
I
wanted
to
talk
about.
So
we've
talked
about.
You
know
rearranging
the
repositories
we've
made
some
progress
on
that
there's.
Some
one
thing
we
talked
about
in
last
week's
meeting
was:
do
we
need
to
continue
to
publish
the
latest
continue
to
publish
stable
artifacts
that
we
that
are
deprecated,
that
we
no
longer
wish
to
make
updates
to
there's
a
number
of
examples
of
this
there's
the
jaeger
protos
we
published
that
that's
deprecated.
C
We
don't
want
anyone
to
use
that
there
is
the
aws
propagator,
which
you
know,
we've
argued,
maybe
should
live
and
contrib
we
we
can
make
an
exception
to
that,
but
it's
more
appropriate
home
would
probably
be
contributed.
Given
the
state
of
the
spec,
there
is
the
the
resource
providers,
so
the
kind
of
main
resource
provider
which
we've
talked
about
moving
to
instrumentation
as
a
more
appropriate
home.
C
Too,
I
suppose
yeah
annotations
and
then
the
aws
resource
providers
as
well,
and
so
all
of
these
are
stable,
artifacts,
that
we've
decided,
you
know,
have
a
more
appropriate
home
and
hopefully,
a
permanent
home.
Hopefully
don't
we
don't
flip-flop
on
these
issues,
and
so
the
we've
talked
about.
Do
we
need
to
continue
to
publish
this
code
forever
and
last
week
we're
floating
the
idea
of
no?
Maybe
we
don't.
C
Maybe
we
can
just
stop
publishing
it
at
some
point
and
if
we
need
to
make
changes
for
security
or
bug
or
anything,
we
can
patch
the
old
latest
version
that
we
had
published.
So,
for
example,
if
we
stop
publishing
jager
protos
at
1.18
and
then
we
need
to
make
some
change
to
it,
I
don't
think
that
that's
likely
at
all,
we
could
publish
1.18.1
to
include
those
changes
and
john
suggested.
Maybe
we
can
customize
the
bom
to
ease
user
migration
of
this,
and
so
we
can
reference
in
the
bomb.
C
The
the
latest
published
version
of
these
artifacts
that
we
stop
publishing
and
so
I've
experimented
with
that
and
it
works.
And
so
I
think
that
that
you
know
that's
a
viable
path
forward,
and
you
know
I
guess
I'm
just
trying
to
feel
out.
Do
we
still
do
we
still
like
this
plan?
E
I
think
it's
still
a
good
plan
and
I
think
putting
it
in
the
putting
the
old
the
last
published
version
in
the
bomb
is
a
good
user,
easy,
relatively
easy
good
user
friendly
thing
we
can
do,
especially
since
there's
no
reason
why
they
won't
continue
to
work.
They'll
work,
just
fine
they're,
fully
backward
compatible.
C
C
But
it
has
a
series
of
tests
that,
like
ensure
that
the
api
follows
a
certain
set
of
standards,
and
you
know
we
can-
we
can
use
this
to
ensure
that
we
can
easily
access
these
deprecated
artifacts
from
the
bomb,
and
you
know
just
reference
those
classes
and
ensure
that
they're
they
they
still
can
be
loaded
or
whatever.
Just
to
keep
us
honest.
E
B
B
I'm
definitely
pro
on
stopping
publishing
these
I'd
say
I'm
neutral
on
the
bomb,
but
if
we
feel
like
that
is
helps
us
to
stop
publishing
then
sounds
good.
E
I
think,
for
example,
like
the
spring
boot
bombs,
which
is
a
funny
sounding
phrase.
I
think
they
have
mixed
versions
because
they
pull
in
different
pieces
of
the
spring
ecosystem,
which
aren't
versioned
in
sync.
A
Great
point,
I
think,
that's
true
they're
also
pulling
a
lot
of
like
third-party
stuff,
different
connection,
pools,
http
clients
and
all
various
kinds
of
things.
C
A
B
A
Really
have
anything
I
mean,
but
maybe
except
mentioning
my
prs,
especially
the
one
about
men
attributes
which
is
just
humongous,
but
the
first
comment
is
kind
of
small
and
contains
that,
like
all
the
actual
changes,
the
rest
of
them
is
just
making
the
things
of
the
code
compile
and
work
so
yeah.
C
A
I
think
it's
also
probably
sort
of
related
to
the
resource
providers.
In
general
I
mean
how
do
we
want
to
work
with
these
ones?
We're
gonna
start
doing
them,
because,
if
their
normal
library
instrumentations,
they
won't
be
picked
up
by
the
java
agenda
process
and
they
won't
be
included
like
automatically.
B
So
materials
is
that?
Because
that's
because
when
we
bundle
up
the
java
agent,
we
loop
through
all
the
modules
and
look
for.
If
it
has
the
java
agent
instrumentation
plugin
yeah.
A
We
look
for
either
boots
device
in
bootstrap
or
javagen
instrumentation.
We
only
add
these,
and
usually
those
generation
instrumentations
that
they
use
a
library
instrumentation.
They
included
acid
implementation
dependency,
so
the
kind
of
like
transitively
included
generation,
but
this
one
is
not
really
referenced
by
anything.
B
A
A
Yeah
I
mean
for
this
pr.
It
would
be
fine
for
me.
We
just
think
hardcoded
the
dependency
in
the
java
build
file,
but
we
will
probably
want
a
concrete
solution.
Next.
D
The
other
and
other
problem
that
we
will
have
when
we
bring
the
resource
providers
over
is
some
of
these
ones
that
are
like
what
I've
described
is
like
opportunistic
words
or
like
the
fallback
strategies.
D
A
D
A
Yeah,
I'm,
although
I
actually
think
that
this
should
apply
methods
really
benefits
from
the
ordering,
because
if
you
older
these
providers,
yeah
in
in
some
way
in
some
sequence,
then
the
the
providers
that
get
called
later
will
see
the
resources
built
by
the
aerial
ones.
So
you
will
be
able
to
decide
bands
based
on
the
earlier
results,
whether
you
want
to
do
something
or
not,.
B
B
Yeah
with
the
default
I
just
mean
like,
is
there
a
way
we
could
apply
this
to
some
existing
resource
providers?
You
know
for
a
few
months
kind
of
see
how
that
feels
before
committing.
A
Without
changing
the
interface,
I
suppose
we
could
use
reflection
to
check
if
should
apply,
method
exists
on
the
implementation
bus,
but
that's
kind
of
dirty.
A
D
A
A
B
D
C
Been
following
this
very
closely,
but
so
you
know:
are
there?
Are
there
one
or
two
concrete
situations
where
this
would
like
materially
benefit?
I
think
yeah.
D
Yeah
the
spring
one
explicitly,
I
I
don't
want
to
override
the
service
name
from
the
spring
resource
detector,
that's
like
snarfing,
the
application
name
and
putting
it
into
service
name.
I
don't
want
to
do
that
if,
if
another
component
has
already
set
the
service
name
on
the
resource
right,
because
it's
kind
of
it's
kind
of
a
last-ditch
effort-
and
there
could
be
something
more
meaningful
that
has
already
put
that
in
there,
like
another
resource
provider,.
A
I
suppose
it
would
probably
also
make
sense
if
we
have
like
more
than
one
research
provider
that
sets
the
hosting,
for
example,
the
cloud
research
providers
like
gcp
or
aws
versus
the
real
actual
hostname,
which
in
case
of
containers,
I'm
just
rubbish
yeah.
You
would
probably
want
to
run
the
container
one
later
and
if
it
detects
that
there
already
is
a
hosting,
then
you
just
skip
it.
B
A
Yeah,
but
with
with
ordering
you're,
not
skipping
a
potentially
expensive
computation,
you're,
just
applying
everything
and
whatever
ends
up
being
the
final
result,
it
is
here
you
can
skip
the
computation
like,
for
example,
the
spring
or
some
servers
things
that
we
have
in.
C
B
That
was
sort
of
my
related
to
my
question
about.
Can
we
could
we
implement
this
in
a
way
that
we're
not
buying
into
the
public
api
yet
so
that
we
could
see
it
in
some
real
examples
could
help
people
to
feel
confident,
because
it's
hard
to
it's
hard,
I
think
adding
public
api
is
going
to
be
challenging
going
forward
and
so
the
more
we
can
get
examples
or
explore
it.
First,
in
real
in
the
real
world,
the
more
we
can
get
buy-in
from
people.
B
C
If
we,
what
if
we
put
an
api
like
a
new
interface
in
the
an
internal,
an
internal
package
of
the
spi
module
and
called
it
something
like
conditional
resource
provider
and
it
just
duplicated
the
resource
or
it
extended
the
resource
provider
interface.
With
this
additional
method-
and
you
know
we
could
just
load
it-
this
additional
kind
of
internal
experimental
spi,
just
the
way
we
load
other
sbis
and
conditionally
apply
them.
A
You
should
you
should
just
load
the
normal
resource
providers
and
just
check
with
an
instance
of
if
it
happens
to
be
a
conditional.
C
Yeah
and
then
you
know,
if
we
we
can
look
at
a
couple
of
cases
where
conditional
resource
providers
are
actually
implemented
and
what's
that,
what's
the
rule,
three
implementations,
that's.