►
From YouTube: 2021-03-04 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Oh
sergey
you're,
lightstep,
right,
yeah,
hi,
so
there's
a
bug
somebody
logged
in
hotel
java.
That's
still
appears
to
be
light
step,
specific
yeah,
yeah.
You
get
anyone
from
lightstep
to
look
at
it
yeah.
We
already
started
to
look
at
it.
Yes,
it
looks
like
in
there
it's
on
the
back
end
of
the
light
step.
A
C
C
I
will
get
sharing
going
here
and
nikita.
Maybe
you
want
to
start
with
your
the
your
wrench.
D
D
D
Every
every
http
library
which
is
based
on
nati
and
which
supports
in
one
way
or
another
request,
pipelining
sending
several
requests
on
the
same
like
channel
connection.
What
not
will
be
broken
because
our
native
instrumentation,
like
assumes
that
if
we
write
some
request,
then
the
next
response
that
will
come
to
this
native
channel
belongs
to
that
request.
D
C
Yep,
I
can't
disagree
yeah.
I
was
pretty
worried
about
pipelining
when
reviewing
those
recent
prs.
Also.
C
C
D
Well
native
server,
I
assume
should
be
easier
or
even
okay,
because
you
don't
okay,
you
still
need
that.
You
still
need
to
like
correlate.
Spam
start
spam
end.
C
D
Yeah,
but
they,
but
they
they
are
not
connected
in
any
way.
C
And
you
can't
get
the
request
because,
like
the
request
could
be
something
that
like
if
we
could
stick
the
context
in
the
request,
but
the
request
doesn't
get
connected
to
the
channel.
I
guess
the
request
is
just
an
object
sent
through
the
channel.
Well,.
D
D
D
C
C
D
At
least
blows
so.
C
What
does
reactor
nettie
I
haven't
looked
at
that?
Is
it
an
actual
http
client
or
does
it
just
bridge
reactor.
C
C
D
D
D
D
D
D
C
My
claims
I
I'll
I
will
talk
to
anurag
this
evening
and
see
if
ask
him
to
reach
out
to
treston
and
I'll
get
his
thoughts
because
they
worked
together.
C
Yeah,
that
would
be
awesome
yeah,
because
it
is
a
big.
It
is
a
big
thing
to
pull
out,
so
it
would
be
helpful
to
be
able
to
point
people
in
the
future
to
some
really
clear
tests
that
fail.
C
A
Yeah
and
there's
and
you
didn't
hadn't,
opened
up
a
new
bullet
point,
there's
actually
a
whole
bunch
of
stuff.
Underneath
that
bullet
point
all.
A
A
The
code
is
very
rough
and
I
would
love
some
help
in
trying
to
maintain
it.
Help
maintain
it
really.
If
there's
somebody
who
knows
spring
cloud,
sleuth
really
well,
it
would
be
very
helpful
because
I
know
the
opens
monetary
apis
really.
Well,
it's
clear
that
marching
who's
the
main
maintainer
over
there
knows
the
sleuth
apis
really
well,
but
bridging
them
is
actually
quite
tricky
and
the
current
state
of
things
is
fairly
broken
and
could
really
use
some
love.
A
So
this
is
just
a
call
to
for
other
people
to
come
help
spring
cloud.
Sleuth
is
a
is
a
popular
project.
Spring
is
obviously
a
big
target
for
java
engineers
and
it
would
be
really
helpful
to
have
a
better
integration
between
the
two,
so
yeah,
just
mainly
a
call
for
some
help,
because
I
don't
I
can
do
pieces
and
parts
here
and
there,
but
would
love
some
additional
help
with
it.
So
I
had
a
couple
other
bullet
points
that
I
threw
in
there
context
propagation
is
sort
of
kind
of
working.
A
I
chatted
a
little
bit
with
honorag
about
it
and
we
think
probably
we
can
do
it
with
a
a
lot
more
simply
than
what's
in
there
right
now,
it's
really
a
mess.
At
the
moment
I
had
to
fix
a
pretty
significant
bug
with
the
way
it
was
working
because
it
was
totally
not
working
at
all
recently,
but
the
baggage
propagation.
A
I
don't
understand
sleuth
baggage
and
would
love
some
help
in
trying
to
figure
out
how
to
do
sleuth
baggage
propagation
correctly
and
then
there's
my
final
question,
which
so
sleuth
has
instrumentation
a
whole
bunch
of
instrumentation,
a
lot
of
which
overlaps
with
agent
instrumentation.
A
It
would
be
really
great
if
we
didn't
have
to
rewrite
all
that
instrumentation
that
we
don't
have
right
now
in
the
agent.
If
there's
some
way,
we
could
reuse
it
some
sort
of
bridge
or
something
just
really
brainstorming
it'd
be
really
great.
If
there's
a
way,
we
could
share
help
try
to
share
instrumentation
between
the
projects
or
provide
a
bridge
between
them.
C
Do
you
how
about
do
you
know
where
we
can
see
the
list
of
instrumentation
that
they
have
if.
A
C
And
in
particular
the
instrumentation
they
have,
which
is
native
sleuth,
instrumentation
versus
brave
yeah,.
C
A
A
C
Yeah,
it
would
be
so
which,
like
I
know,
we
don't
have
courts
instrumentation.
We
don't
have
spring
messaging
instrumentation
spring
messaging.
C
Oh
at
the
met
yeah
I
mean
usually
that
spring
messaging
is
using
right,
a
rabbitmq,
a
rocket
mq
jms
kafka.
So.
C
C
B
C
Cool
yeah.
I
definitely
encourage
at
least
folks
to
watch
the
this
repo
would
be
really
helpful
so
that
we
can
kind
of
keep
up
to
date
and
chime
in
and
help
out.
A
C
A
Getting
started
right
so
it
would
be
really
good
to
take
a
look
and
see
what
they're,
how
they're
using
it
to
inform
how
we
want
to
design
the
api.
C
Cool
yeah.
I
totally
agree
that
I
mean
this
is
a
really,
I
think,
important
project
for
our
community,
also
because
of
how
critical
spring
is
and
we
had
discussed
with
them
with
marching
a
while
back
about
potentially
having
them
host
and
maintain
sort
of
the
spring.
Our
spring
boot
instrumentation
that
materish
was
cleaning
up
that
auto
configure
stuff
and
they
seemed
interested
in
you
know
having
people
in
the
spring
community
go
use,
sleuth
and
use
their
auto
configure
stuff,
and
so
that's
yeah.
C
There's
a
lot
of
collaboration
in
the
future.
Yep.
A
C
A
Thanks
which
actually
dovetails
very
nicely
with
mateosh's
next
item
there,
because
I
know
that
there
will
be
people
who
run
sleuth
and
turn
on
the
agent,
and
things
do
not
go
well
in
that
mode.
I
can
attest.
B
Yeah,
I
was
digging
through
all
these
old
issues
about
instrumentation,
api
context,
tracers
and
all
the
stuff,
and
I
posted
a
comment
with
an
idea
that
maybe
we
could
disable
the
divided
instrumentations
if
we
detect
the
library
instrumentation
classes
on
the
class
path,
which
I
think
ties
nicely
with
what
anarch
has
been
doing
recently,
you
know
he's
been
creating
all
those
like
one
class
to
configure
the
whole
library,
and
I
wanted
to
ask
you
what
do
you
think
about
it,
because
I
remember
that
I
think
it
was
your
comment,
trust
that
you
said
that
the
java
agent
instrumentation
should
probably
take
precedence
and
should
turn
off
the
library
instrumentation.
B
C
B
So
well,
maybe
not
really
muzzle.
We
could
just
have
an
additional
class
order,
matcher
that
checks.
If,
if
our
library
instrumentation
classes,
we
can
just
turn
off
the
whole
instrumentation
module
and
skip
it.
C
So
the
reason
why
I
have
was
thinking
the
the
reason
behind
my
thought
on
the
java
agent
taking
precedence
is
that
that's
typically
easier
for
people
to
update
to
keep
updated
to
get
the
latest.
We
still
have
different
opinions
on
on
that
and
that
that's
yeah,
that's
fair.
I
think
it's
definitely
there's
probably
not
a
an
official
right
way.
I
wouldn't
I
wouldn't
fight
fight
it
too
hard.
If,
if
people
prefer
to
have
the
library
instrumentation
take
precedence,
there's
there's
definitely
some.
D
Logic:
yeah
one
more
argument
in
favor
of
turning
off
agent
instrumentation
is
that
if
and
when
the
library
itself
starts,
you
starts
using
open
telemetry,
we
will.
We
will
switch
off
our
agent
instrumentation
in
exactly
the
same
way.
We
just
detect
that
there
is
some
class
and
we
back
off
so
that
that
way
we'll
we
will
be
consistent.
D
If
we
detect
either
our
library,
implementation
native
library
instrumentation,
then
the
agent
will
back
off.
C
C
All
right:
well,
let's
do
what's
easier
and
I
mean
it
certainly
makes,
but
I'm
convinced
by
those
being
totally
valid
reasons
to
for
library
to
take
precedence.
B
Okay,
that's
cool
I'll,
try
to
put
a
draft
pr
this
week
or
early
next
week.
C
Nice
yeah
yeah
it's
kind
of
exciting
that
we're
getting
our
first,
so
oh
yeah,
so
I
should.
I
don't
think
we
chatted
in
this
group.
We
chatted
last
thursday
night
with
onorag
and
bogdan
about
one
zero
java
agent
or
no
one
zero
library,
instrumentation.
C
So
we
were
the
instrumentation
api.
Artifact
is
nowhere
close
to
being
stable,
so
that
that's
you
know
still
alpha.
So
we
were
kind
of
thinking
that
we
couldn't
release
any
library,
stable
library
instrumentation
until
we
stabilized
the
instrumentation
api
artifact,
but
discussing
with
onorag
and
bogdan
actually
bogdan's
idea
of.
C
If
we
just
you
know
only
exposed
in
the
library
instrumentation,
these
very
narrow
apis
public
api,
like
grpc
interceptor,
create
a
new
grpc
interceptor
and
then
package
protect
the
tracer,
the
instrumenter
the,
and
so
we
only
give
you
know
that
very
small
api
we
could
declare.
We
could
have
that,
be
one
zero
stable.
C
C
C
C
Okay,
yeah
a
very,
very
helpful
and
very
nice
that
we
can
mostly
just
reference
that
doc
from
here
so
from
an
api
stability
perspective
we're
following
those
except
for
that
we're
allowing
incompatible
changes
to
stable
artifacts
in
these.
These
specific
incompatible
changes,
meaning
telemetry
that
we
produce,
and
then
this
is
the
spec
issue.
That's
talking
about
what
telemetry
stability
would
mean
in
the
future,
but
for
now
we're
we're
not
putting
having
any
guarantee
around
telemetry
stability
and
then
config
properties.
C
So
we've
been
putting
a
lot
of
stuff
behind
experimental
properties
or
renaming
properties
and
then
anything
under
this
config
properties.
Under
this
namespace
and
materish,
I
saw
your
comment
about.
There
was
oh
yeah.
The
spring
batch
chunk
new
trace
like
if
that
should
be
experimental,
and
so
I
will
put
together
a
list
of
the
remaining.
C
Properties-
and
I
was
okay,
I'm
okay,
if
we
want
to
declare
them
stable,
but
I'm
also
okay,
if
we
want
to
put
them
under
experimental
because
kind
of
my
thought
one
thought
is,
we
still
have
an
out
that
anything.
C
We
could
still
change
them.
I
mean
it's
we're
not
going
to
break
anything
and
the
telemetry
produced
would
be
different,
but
definitely
if
we
think
that
they,
if
we're
not
really
that
confident
with
them,
we
should
throw
them
under
experimental,
so
that
particular
one
the
spring
batch.
B
Yeah,
I
I'm
not
even
sure
if
this
is
used,
or
this
is
needed
by
anybody.
So
just
it's
anyway,
it's
pretty
strange
to
break
break
up
a
single
job
to
several
traces,
just
because
the
the
whole
trace
for
the
whole
job
would
be
absurdly
huge.
So
I
don't
know
I'm
not
too
convinced
about
this
property
if
nobody.
A
D
B
C
C
You
know
some
of
the
library
instrumentation
stable,
although
we
should
probably
hold
on
that
I'll
I'll
see
what
he
thinks
nikki
did
you
have
any
initial.
C
C
Else
I
will
ask
just
because
for
anybody
who,
on
the
neti
question,
I
was
just
kind
of
curious
from
cause.
I
know
that
you
know
other
a
that
has
been
a
traditional
instrumentation
for
apm
vendors,
so
wondering
from
you
know
from
a
new
relic
perspective.
C
Is
that
is
that
something
that
you
wish
that
you
had
didn't?
I
mean
I'm
assuming
you
know
based
on
customer
demand.
You
know
customers
can
be
like,
oh,
but
I
need
this
instrumentation
or
is
it
something
that
hasn't
really
given
you
that
much
problems
in.
E
No,
I
can.
I
can
comment
on
that.
I
I
missed
the
beginning
of
this
meeting,
so
I
didn't
get
to
hear
what
the
neti
issue
actually
was,
but
I
can
I
can
confirm
that
neti
and
you
know,
like
spring
web
flux,
just
any
spring
reactive
code,
really.
Those
are
like
our
biggest
pain
points
always
and
they're.
Also
some
of
the
most
widely
used
instrumentations
by
customers,
but
yeah
the
hardest
instrumentation
to
maintain
by
far.
D
D
C
To
clarify
we're
talking
about
nettie
potentially
pulling
out
the
neti
client
instrumentation,
only
not
the
neti
server
instrumentation,
because
it
feels
like
the
nitty
client
instrumentation
is
where
we're
having
concern
problems
and
concerns
specifically
around
http
pipelining.
C
E
Yeah,
I
was
thinking
of
our
like
neddy
reactor
instrumentation.
I'd
have
to
I'd,
have
to
go,
dig
in
and
see
exactly
what
all
we
have
around
nettie,
because
it's
not
an
area
that
I'm
a
expert
in
but
yeah.
I
was
gonna
ask
if
there's
where
I
can
find
the
recording
of
this.
So
I
could
catch
the
the
intro
on
the
net
issue,
and
maybe
I
can
get
back
to
you
with
more
details.
C
Cool
it
should
get
posted
to
youtube
in
a
few
hours
and
also
nikita
is
going
to
post
a
test
into
our
repo.
Are
you
on
the
slack
on
the
new
slack
channel?
C
Slack,
we
do
not
community,
let's
see
slack
yeah,
everyone.
A
C
Join
the
cncf
slack
open,
telemetry
slack
channel
slat
here-
let's
put
this
here-
please
join.
C
C
Cool
so
nikita,
maybe
you
can
post
whenever
you
have
that
pr
to
the
to
our
the
hotel
java,
instrumentation
channel.
C
Awesome
anything
else
anyone
wanted
to
chat
about
today.