►
From YouTube: 2023-01-12 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
B
C
A
This
so
I
approved
this
I
thought
it
was
a
nice
simple
example
of
testing
Telemetry
from
Auto
instrumentation,
so
spinning
up
it
spins
up
a
mock
grpc.
A
A
Client
and
server
yeah,
so
it
spins
up
a
mock.
Grpc
endpoint
points,
the
the
Java
agent,
so
it
runs
with
the
Java
agent
pushes
Telemetry
to
that.
Okay,
ATP
protobuf.
A
So
it's
going
to
go
to
the
default
or
localhost
whatever.
That
is,
and
then
it
verifies
that
that
span
data
at
the
protobuf
level.
A
Right.
It's
not
it's
not
as
nice
say
as
the
integration
tests
we
have,
which
use
the
the
SDK
testing
infra,
which
gives
us
those
nice
assert
J
assertions,
but
we
don't
really
have
a
simple
way
for
users
to
reuse
that
that
infrastructure
yet
and
we've
gotten
we've
had
this
question
a
couple
of
times
of
how
people
can
do
testing
of
their
Auto
instrumentation
or
their
like
if
they
do
custom
instrumentation
inside
of
their
app
and
they're
running
the
Java
agent.
How
to
validate
that.
A
So
it
seemed
worth
merging
to
me
just
wanted
to
see
if
there
was
any
thoughts.
Any
objections.
E
E
D
So
this
mock
server-
this
is
surrounding
in
a
separate
process,
or
this
is
in
process,
didn't
quite
get
that.
A
No,
it's
not
working
so
I
think
the
Java
agent
is
getting
added
to
the
test
itself
and
then
the
inside
the
test.
It's
running
the
mock
server
in
process.
D
D
A
C
So
trust
just
so
I
understand
this
is
to
this
is
because
it's
hard
to
when
you're
using
the
agent.
You
know
it
would
be
challenging
to
have
some
sort
of
in-memory
exporter
that
you
could
access
from
the
test
code.
A
C
And
you
you
all
jumped
through
some
hoops
in
the
in
the
instrumentation
repository
by
like
serializing
that
and
then
deserializing
the
protobuf
bites.
A
Yeah
so
the
everything's
in
the
isolated
agent
class
loader
and
so
to
get
that
get
it.
We
have
to
get
it
over
into
the
test,
class,
loader
and
so
yeah
I
think
I'm,
pretty
sure.
That's
what
we're
doing
is
just
to
bypass
the
class
loader.
The
two
different
class
loader
cloud
issue.
C
B
There
is
still
the
application
logging
PR,
open
and
yeah.
It's
a
tough
one.
A
A
Yeah
but
I
was
motivated
before
so
I'm
late
on
that
we're
late
on
the
release
supposed
to
go
out
yesterday,
it's
in
process
of
going
out
today,
right
now,
I
wanted
to
get
in
all
of
the
spring
boot
3
related
PRS,
since
more
and
more
people
have
been
reporting
issues
with,
you
know
spring
six
and
our
instrument
at
the
auto
instrumentation.
A
So
we
haven't
updated
the
spring
batch
instrumentation
or
the
spring
integration
instrumentation.
Yet,
but
the
GMS
Kafka
everything
else
not.
B
Exactly
in
the
spring
web
services,
one
also
needs
an
update
because
it
uses
jaxby
and
jaxby
had
the
same
javax
to
Jakarta
changed,
and
the
library
instrumentation
for
sporting
webflux
has
absolutely
no
dust
whatsoever.
So
I
have
no
idea
if
it
works
or
not.
A
B
B
I'm
planning
to
add
some
tests
to
this
one-
maybe
tomorrow
maybe
next
week,
because
it's
the
last
thing
that
blocks
us
from
updating
the
auto.
Let's
start
the
spring
starter:
module
to
3.0.
C
So
then,
the
for
example,
some
of
the
libraries
that
have
been
updated
like
spring
web
MVC.
Those
will
have
new
library,
artifacts
published
with
this
release.
That
includes
the
Jakarta
filter.
E
Like
based
on
the
source
code,
but
yeah,
you
just
want
to
make
sure
there's.
G
B
C
A
Cool,
that's
great,
so
the
web
NBC
has
a
separate
artifact
you're
asking
one
other,
though.
A
A
A
Has
been
to
so
dropping
support
for
older
Library
versions,
the
Java
agent
instrumentation
were
pretty.
We
generally
maintain
all
the
old
versions
since
it's
often
used
by
people
on
their
legacy.
Apps
that
they're,
not
updating,
but
our
thought
for
Library
instrumentation
generally,
is
that
users
are
who
are
using
Library
instrumentation
are
updating
their
source
code
anyway,
rebuilding
redeploying
their
app
anyway,
so
there's
less
likely
hit
of
them
having
to
stay
on
old
versions
of
the
library.
A
So
we
tend
to
drop
older
versions
of
Library
instrumentation
much
more
quickly,
but
I'm
wondering
if
spring
boot,
two
three
is
obviously
more
convenient
for
us.
If
we
can
drop
the
old,
but
I
don't
know,
is
there
any
like
in
the
spring
universe?
H
I
I
just
said
the
link
to
the
or
posted
Link
in
the
chat.
So
if
you
open
it,
you
will
see
the
the
support
life
cycle
of
the
different
versions.
So
based
on
this
right
now
are
the
end
of
the
life
of
R2.
Is
that
date
this
year,
November
right
now
we
are
not
planning
to
have
a
to
the
date.
It
doesn't
mean
that
it
won't
be,
but
it's
very
likely
that
it
won't
be
any
any
to
the
date.
So
2
7
is
d.
H
Is
the
latest
version
of
the
two
attack
sign
and
it
should
go
out
of
support
in
November.
A
And
mates
I
think
you
were
planning
on
the
and
it
probably
on
the
spring
boot
starter.
A
H
I
I,
just
wanted
to
like
call
out
just
FYI
spring
framework,
has
like
a
different
like
support
lifestyle
code
right
now,
then
boot
so
boot
to
the
text
is
supporting
framework
file,
attacks
and
boot.
Three
support
stream
work.
H
Six
and,
as
you
can
see
in
the
support
page
like
the
framework
like
five,
it's
end
of
life
is
like
well
a
year
after
boot
tree
sorry
boot
two,
and
this
is
because
you
still
have
users
who
are
just
using
like
the
vanilla
framework
and
they
are
not
using
Auto
configuration
input.
H
So
if
you
are
talking
about
the
instrumentation
for
different
components,
check
out
these
dates,
they
can
be
different
for
you,
for
example,
webmdc
is
nothing
boot,
it's
in
framework
and
that
will
be
supported
to
2024.
B
B
We're
using
the
same
versioning
scheme
as
the
agent
and
we
don't
really
encode
like
the
spring
version
in
its
name,
which
makes
it
kind
of
problematic,
because
we
cannot
just
simply
bump
the
minor
version
and
have
a
Target
Spring
free,
because
it
would
pretty
much
I
think
be
just
you
know.
Stopping
supporting
swing
through.
A
H
What
I
saw
in
a
couple
of
cases
is
that
they
basically
like
just
really
is
a
new
like
nature
version
and
they
are
keeping
the
previous
one
live
deal
groups
2
is
alive,
like
I
haven't
seen
that
happening
because
we
still
have
a
year
for
for
that.
But
that's
what
the
plan
for
for
quite
a
few
libraries
I
guess.
A
Given
the
state
of
our
spring
boot
starter
that
it
has
a
lot
of
Paul's,
still
I,
wonder
if
it's
more,
if
that
or
if
that's
a
reason
or
justification
for
us
to
drop
to
sooner.
B
I,
honestly,
like
have
no
idea,
we
seem
to
have
some
users
of
that.
There
are
people
who
like
file
issues
and
are
very
happy
when
we
feed
them,
but
I
didn't
know
what
version
the
good
version
of
the
screen
they're
using
and
if
they
will
be
very
unhappy.
If
we
just
scrap
speak
to.
B
A
F
C
C
C
So
there's
a
pretty
active
conversation
yesterday
about
about
login
event
apis
and
their
dependencies
and
I
think
I
think
most
I
think
everyone's
pretty
much
in
agreement
and
I.
Think,
despite
what,
despite
what
I
was
originally
interpreting
Anthony
as
saying
you
know,
I
I
guess
my
original
read
was
that
he
thought
that,
like
the
event,
emitter
provider
should
accept
a
a
logger
provider
as
an
argument
but
I
think
kind
of
I
I
was
misunderstanding
him
and
what.
F
C
Actually
is
saying
is
that
in
the
in
the
implementation
of
the
event,
emitter
provider,
that
the
implementation
is
provided
a
logger
provider,
so
it's
an
SDK
level
detail
in
our
world,
and
that
seems
reasonable
to
me
right
about
SDK
using
logs
and
the
event.
Sdk
is
just
like,
essentially
just
a
really
thin
wrapper
that
accepts
a
a
logger
provider
and
you
know
delegates
to
it
and
if
folks
agree
with
that,
then
I
can
update
the
pr
that
I
have
to.
C
You
know
Implement
that
it's
it's
a
really
simple
set
of
changes
actually
and
we
can
move
forward.
A
Yeah
I,
I,
agree
and
Peter
if
you're
not
following.
You
may
want
to
watch
this
discussion
this
issue,
just
because
I
thought
of
you,
because
you
had
mentioned
previously,
that
you
were
hoping
that
the
event
API
would
not
be
like
strictly
bound
to
the
log
API,
so
that
I
think
you're
interested
in
being
able
to
have
your
own
implementation
of
the
event.
Api
well,.
D
C
Seems
to
meet
all
my
design
criteria,
so
you
know
the
users
of
the
event.
Api
don't
have
to
be
aware
of
the
log
api's
existence
right
and
it's
still
possible
to
provide
alternative
implementations
of
the
event
API.
Besides
just
the
log
SDK,
but
there's
tooling,
to
make
the
log
SDK.
You
know
a
really
easy
plug-in
for
ASLA
the
implementation
of
the
event
API.
G
Yes,
yeah
I
mean
this
seems
like
a
fine
interim
solution.
I
suspect
this
will
not
work
long
term
because
I
think
it's
going
to
make
it
annoying
to
have
to
redirect
events
to
a
different
back
end
than
regular
logs.
But
that
doesn't
bother
me
because
it's
not
hard
to
solve
I.
E
G
C
People
were
in
more
agreement
than
was
originally
apparent,
and
then
you
know
I
think.
What
also
was
clear
in
that
conversation
is
that
there's
pretty
strong
support
of
keeping
like
a
log
API
for
the
the
Pender
use
case,
and
you
know
keeping
the
language
where
this
log
API
isn't
supposed
to
be
used
outside
of
appenders.
C
So
that
allows
us
to
that's
beneficial
for
us,
where
you
know
we
don't
we
don't
want
to
have
the
appenders
take
a
dependency
on
the
SDK,
the
log
SDK
because
of
the
class
loader
issues
that
we've
discussed
so.
A
Thank
you
for
driving
representing
all
of
us
in
those
discussions.
C
And
thanks
for
chiming
in
I
appreciate
it,
it
helps
when
it's
when
it's
more
than
one
voice
exactly.
G
C
G
C
G
A
All
right,
y'all,
Final
Call
for
topics.