►
From YouTube: 2021-03-12 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
D
You
can
even
see
the
the
peninsula.
D
A
A
D
B
B
B
C
B
We
have
this,
is
today
all
right,
somebody
else's
typing
awesome
and
we
have
nothing
on
the
agenda.
That's
not
too
surprising
for
the
start
of
the
meeting.
B
Hey
right:
well,
let's
open
it
up
on
topics.
A
A
little
more
driven
by
like
user
need,
so
I
put
a
pr
into
the
open,
telemetry
java
repo
yesterday,
which
put
I
don't
know
if
you
actually
want
to
jump
over
there
and
just
see
what
I
did
so,
the
very
top
of
the
readme
I
added
a.
I
ended
up
getting
started
at
the
very
top
of
the
readme
for
not
enough
not
instrumentation
for
java
itself.
A
B
A
This
one,
probably
the
open,
telemetry
java
instrumentation
and
the
contrib
and
the
public
docs
to
try
to
just
get
people
oriented
to
go
to
the
place,
that's
going
to
fulfill
what
their
needs
are,
and
I
wondered
if
other
people
had
opinions
on
this.
B
A
Yeah
so
I'd
like
to
try
to
put
something
similar
in
the
top
of
the
readme
for
instrumentation
as
well,
so
I'd
probably
hopefully
be
maybe
putting
that
pr
in.
I
don't
know
if
I'll
get
to
it
today,
but
sometime
in
the
next
few
days,
and
if
people
have
other
ways
to
approach
this,
I
mean
I
just
kind
of
quickly
wrote
some
wrote
some
words,
but
there's
there
possibly
more
personas
and
any
more
help
for
making
this
easier
for
users
would
be
would
be
great.
B
Yeah,
I
wonder
if
it's
worth
breaking
out
the
users,
people
who
are
writing
instrumentation
inside
of
a
library
that
they
are
managing
like
and
honorable's,
been
helping
like
the
vertex
and
couch-based
communities.
A
Yeah,
so
we
I
wouldn't,
we
need
to
actually
write
some
documentation
like
that
right,
because
I
don't
think
we
have
anything,
that's
really
oriented
towards
towards
that,
and
because,
when
you're
like,
if
you're
going
to
write
instrumentation,
there
are
there's
probably
like
three
main
things.
You
need
to
seriously
consider
and
think
about
right.
We
need
to
think
about
number
one
context
propagation
like
that.
I
think
one
needs
to
think
about
that
up.
Front
is
the
first
thing
like
is
this
relevant?
Is
it
important?
A
So
probably
if
we
could
write
like
a
little
how
to
write
instrumentation
or
how
to
approach
writing
instrumentation
for
library
authors.
That
would
probably
be
great
and
very
helpful.
B
Yeah-
and
it's
some
I
mean
that
sort
of
dovetails
into
the
instrumentation
api
prod
module
and
whether
we
would
I
mean
I,
I
think,
we're
starting
to
go
in
the
direction
of
thinking
that
we
would
want
to
recommend
that
for
library,
especially
library,
instrumentation
authors.
B
Cool
matteos.
D
Okay,
so
we've
been
looking
into
instrumenting
spring
cloud
stream,
which
serves
as
a
sort
of
a
higher
level
abstraction
over
several
messaging
apis.
So
it
can
delegate
the
actual
work
to
kafka,
for
example,
and.
D
We've
encountered
the
problem
of
duplicate
producer,
slash
consumer
response,
and
I
wonder
because
because
there
is
a
nice
symmetry
between
producer
and
consumer
response
and
server,
client
or
client
server
expands,
and
I
wonder,
should
we
do
the
similar
thing
similar
thing
for
producer
consumer
spams,
that
we
do
for
server,
client
spams
in.
A
D
Java
agent
like
if
there
is
already
already
a
producer
spam
in
the
context,
suppress
creating
another
one,
or
maybe,
if
maybe
we
should,
we
could
consider
another
approach
like
if
there's
already
a
producer
or
client
spam.
We
could
enrich
the
already
resisting
one
with
the
data
from
the
lower
level
one.
This
is.
D
This
is
actually
the
the
thing
that
we
would
prefer
to
do
with
the
spring
cloud
stuff,
because
the
spring
apis
are
very
generic
and
they
barely
provide
any
info,
and
if
we
have
a
lower
level
instrumentation
like
kafka
or
jms,
then
it
would
be
data
from
that
we
would
extract
from
it
would
be
much
richer.
D
B
So
is
it,
is
it
reversed
like
say
the
producer,
the
on
the
consumer
side,
the
top
level
would
be
kafka
and
the
nested
one
would
be
the
spring
one.
D
I
think
that
the
mainly
the
problem
that
we've
discussed
and
not
even
encountered
was
the
producer
side,
because,
on
the
consumer
side,
always
the
lower
level
api
would
be
the
first
one,
so
it
would
always
create
the
span
first
and
whatever
we
do
in
the
spring
cloud
instrumentation
it
will
just
it
could
be
a
suppressed
altogether.
It
could
be
an
internal
span,
it
doesn't
really
matter
what
matters
is
the
producer.
D
D
Yeah,
so
on
the
producer
side
spring
is
first
and
it's
the
instrumentation
would
create
a
pretty
bare
span
with
just
a
name,
and
I
don't
know,
I
don't
know
if
you
can
even
extract
the
actual
technology
that
sends
the
message,
whether
it's
kafka
or
rabid
or
whatever
else.
D
So
we
could
just
create
a
burst
pan
and
then
what
suppress
the
actual
producer
spawn
from
the
lower
instrumentation?
If
it's
there,
because
if
it's
not,
then.
F
I
think
on
producer
societies
it
totally
doesn't
make
sense
to
lower
level
instrumentation
to
enrich
the
cloud
messaging
spam
because
yeah
one
one
point
why
you
still
may
want
to
have
producer,
create
it
on
sprint
messaging
level.
Is
that
you
you
already
on
that
level?
You
can
guarantee
context
propagation,
even
if
you
don't
support
the
low
level
technology,
because
on
spring
on
spring
messaging
level,
you
already
can
insert
headers
and
then
it's
their
job
to
translate
to
lower
level
representation.
D
Yeah
and
string
messaging
doesn't
really
know
if,
if
whatever
is
loose
on
the
lower
level,
is
instrumented
by
us
so
yeah
we
cannot
just
skip
it
up
front,
saying
it:
okay,
whatever
it's
surely
kafka
beneath,
because
we
don't.
A
F
From
conclusion,
yeah
for
now
it's
for
now
it's
what
what
the
correct
word
was
for
now.
We
think
that
it's
forbidden,
okay.
B
A
D
Honest
we
in
the
java
agent,
we
barely
provide
any
defense
against
nested
clients,
because
so
some
of
the
client
instrumentation
don't
even
check
if
they
should
start
the
start
span
or
not.
They
just
start.
B
Are
you
had
a
question
about
at
the
the
spring
messaging
layer?
Can
we
do
proper
context,
propagation
or
sorry
span
context
propagation
over
the
wire?
Can
we
set
and
read
headers
at
that
layer.
D
F
Spring
spring
message:
abstraction
does
provide
support
for
headers.
If
lower
level
transport
like
kafka,
does
support
headers,
it
will
be
properly
mapped.
If
there
is
no
way
for
for
lower
level,
then
I
don't
remember
what
spring
does,
but
anyway,
you
certainly
can-
and
this
is
certainly
yeah.
This
is
what
you
meant
up
here.
F
B
Yeah,
I
I
mean
my
feeling
is
a
bit
happy
for
any
change.
You
know
that
doesn't
have
the
nested
spans
so
either
you
know,
if
you
want
to
suppress
or
the
enriching
would
be
cool
to
try
out.
I
know.
F
F
F
D
F
B
Yeah,
I
may
want
to
wait
on
that
for
john's
spec
issue
to
flush
out
a
little
bit.
A
D
F
F
B
C
B
Yes,
honorable
had
something
else
he
wanted
to
get
into.
B
I
haven't
caught
up
on
my
morning,
emails
mateo
sure
nikita
did
the
101
happen
on
the
instrumentation
side.
D
B
I
know
that
honorable
wants
to
make
a
one
zero
one,
because
it
was
his
bug
in
his
bug,
fix
that
he
needed
in
the
hotel
java
project.
So
he
wants
to
release
101
here,
so
he
can
consume
that
in
the
aws
distro.
So
I
I
would.
I
would
expect
that
to
happen
in
the
next
day.
F
F
B
No,
no,
I
I'm
totally
agreeing
this
makes.
That's
a
good
point.
I
think
this
is
the
key
point
that
we
do
need
to
the
job
like
say,
java,
api
releases
1.2.