►
From YouTube: 2021-04-22 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).
B
C
C
C
D
A
E
C
E
D
Hey
good
to
meet
you
jack,
yeah
nice,
to
meet
you
too
this
summer.
We
should
definitely
try
to
have
a
portland
open
telemetry
get
together
again.
D
A
A
A
lot
of
little
like
cleanup
and
test
stuff
in
the
last
week,
this
one
I
haven't
seen
yet
since
I
woke
up
submitted
and
merged
awesome,
we've
got,
but
I
think
this
honra
was
mentioning
this.
There
was
a
problem
with
this
last
week
with
the
grpc
bridge.
A
He
added
a
grpc
bridge
that
bridges
the
jrpc
context
to
our
context,
so
it
stores
our
context
in
the
grpc
context,
so
that
if
somebody
user
propagates
the
grpc
context,
it
will
automatically
propagate
ours,
and
vice
versa,
puts
the
grpc
context
in
our
context,
so
that
if
our
auto
instrumentation
propagates
the
our
context,
it
will
automatically
propagate
the
grpc
context
and
that's
both
a
library,
instrumentation
and
then
also
an
auto
instrumentation
and
the
basic
problem.
A
If
you've
seen
the
way
that
the
grpc
context,
the
way
they
provide
a
hook
for
the
grpc
context,
is
really
weird.
You
create
this
class
with
a
very
specific
name
in
a
very
specific
package
and
it
will
look
and
if
you
have
that
class
it'll
use
that
class
as
the
override,
so
for
library
instrumentation.
We
need
that,
but
for
auto
instrumentation
we
don't
want
that.
We
use
bike
code
magic
and
we
don't
need
to
use
their
official
hook,
but
we
also
don't
want
the
that
class
on
our
class
path.
Otherwise,
we.
F
A
Cool
that
we
have
a
fix
now,
yes,
yeah,
that's
awesome,
hey
we
have
a
new
approver,
so
laurie
from
splunk
has
been
doing
amazing
work.
The
last
few
months
so
really
excited
to
have
laurie
on
the
approvers.
A
Oh,
this
was
reported
by
a
user
yeah.
It
was
something
where
muzzle
couldn't
capture
the
problem.
Why
didn't
muslim
capture
that?
Oh,
I
remember
but
I'll?
Let
matisse
explain.
B
Yeah
so
muzzle
saw
the
reference
to
oh
man
this,
let's
start
from
beginning
we
have
a
tracing
subscriber
or
observer,
or
something
like
that.
That
extends
a
class
from
eric's
java
to,
and
we
referred
to
one
of
the
fields
of
the
base
class.
They
renamed
it
in
some
later
release
and
muzzle
detected
the
reference
to
the
field
in
a
base
class
as
reference
to
the
field
in
this
class
in
our
helper
class.
B
A
A
A
Nothing
nothing.
I
the
only
reason
I
kind
of
bumped.
This
is
because
we
still
we
haven't
we're
not
really
ready
to.
We
ideally
want
to
use
the
spring
cloud
sleuth
for
spring
boot,
starter
or
recommend
users
to
use
that,
but
we're
not
totally
sure.
Like
I
mean
if
that
will
address.
All
of
I
think
there
was
ass
under
about
that
last
week
or
the
week
before,
and
he
wasn't,
you
know,
still
wanted
to
wait
and
see.
A
So
it's
worth
minimal
effort
on
our
spring
boot
starter
where
we're
where
we
can
but
definitely
want
to
and
mateos
maybe
matish.
Do
you
want
to
talk
a
little
bit
about
the
salute?
Your
sleuth
experience
this
past
week.
B
B
Okay,
so
I
tried
to
use
our
new
instrument
or
api
in
a
spring
slew
photo
and
it
actually
went
pretty
well,
there
were
several
some
minor
bugs
like
sleuth,
doesn't
really
allow
you
to
get
host
and
port
information
from
response.
You
have
to
do
it
from
the
request
and
our
instrumental
api.
B
Well,
we
assume
that
it
could
be
resolvable
from
the
response,
so
this
is
just
a
few
minor
things
that
were
discovered
by
me
anyway.
It
went
pretty
well,
it's
quite
easy
to
change
the
the
usage
of
our
previous
tracer
api
to
instrumentor
api.
B
B
But
when
I
was
working
on
that,
I've
discovered
that
I
think
that
this
sphinx
photo
project
may
have
some
major
problems
with
how
they
propagate
context
or
how
they
actually
don't
do
that
and
propagate
just
spam,
and
I
have
like
some
idea
of
how
to
fix
parts
of
it.
But
when
I
opened
their
baggage
implementation,
I
just
don't
know
what
happens
there.
So
it
seems
that
you
probably
need
the
person
who
knows
both
other
and
sleuth
to
implement
this.
D
So
they
they
are
actually
putting
a
span
into
the
context.
It's
not
it's
just
the
way
that
sleuth
does
its
propagation
like
it
has
to
do
both
sleuth
propagation
and
open
telemetry
propagation,
and
it's
actually
it's
super
messy.
It's
very
hard
to
understand
at
the
moment.
I
have
hacked
it,
so
it
generally
works,
but
it's
the
implication.
Implementation
is
quite
messy
at
the
moment.
I
agree.
B
Yeah,
so
one
thing
that
I
that
helped
me
the
most
when
I
was
working
with
that
was
the
fact
that
the
swift
span
has
some
context.
Some
open,
telemetry
context
associated
with
it.
But
it's
there's
no
guarantee
that
this
context
contains
the
same
span
that
this
span
wraps
or
that
it
can
contain
no
span
or
can
contain
barren
span
and
just
by
various
random
hacks.
Everything
is
kind
of
working,
but
that's
far
from
ideal.
D
Yeah
we
definitely,
it
would
be
really
great
since
honorable,
I
think,
knows
the
sleuth
apis
pretty
well.
It
actually
would
be
probably
useful
to
get
a
couple
of
us
to
work
together
on
trying
to
sort
out
the
context.
Propagation
honorark
thinks
that
it
might
be
as
easy
as
just
hooking
up
a
custom,
conte,
storage,
storage
implementation,
but
I'm
not
convinced
anyway.
There's
definitely
work
to
be
done
to
make
that
make
more
sense.
D
D
Right,
it's
just
integrating
with
sleuth,
which
now
the
with
the
the
release.
That
is,
I
don't
know
if
they've
actually
released
it
yet,
but
the
one
that
has
hotel
support,
they've
separated
the
brave
and
the
sleuth,
because
they
used
to
just
be
very
intertwined-
and,
I
think,
still
like
all
of
the
apis
are
essentially
still
the
brave
apis
and
they
don't
mesh
particularly
well
with
the
open,
monitor
apis.
F
Mateosh,
can
you
clarify
so
as
a
and
or
not
just
you,
but
anyone?
I
guess
if,
if
I'm
a
user
of
spring
cloud
sleuth
and
I
have
an
app
and
this
ends
up
getting
merged
one
day,
how
do
I
go
about
using
it
like?
How
do
I
configure
this
and
how
do
I
make
sure
that
spans
are
going
to
the
place
that
I
want
them
to
go
so.
D
F
And
so
we
can
piggyback
or
leverage
all
of
that
spring
configurability
to
configure
otel
as
well.
Oh
there,
it
is
kind
of.
D
F
That's
cool.
Thank
you,
yeah!
I'm
just
thinking
that
you
know
typically
there's
so
much
setup
involved
with
doing
anything
right
like
you,
gotta
tell
it
like
how
to
where
to
send
stuff
and
what
protocol
to
use
and
all
of
that
and
the
user
still
has
to
do
that
somewhere
unless
they
have,
unless
spring
has
really
opinionated
defaults,
which
they
don't.
A
D
Or
you
can
do
it
just
by
you
know
like
creating
the
standard
spring
injection
contact
like
the
annotation,
based
whatever
spring
calls
their
provider
stuff
can
do
it
all
that
way
as
well.
D
A
Okay,
yeah,
I'm
hopeful
that
spring
users
right.
It
is
a
very
spring
spring
solution.
I
mean
the
so
spring
users
are
very
used
to
that,
and
so
I'm
hoping
that
will
work
well
for
them,
as
opposed
to.
If
we
told
them
to
use
open
telemetry
directly
right,
then
they
would
stumble
on
a
lot
of
these
things.
A
Well,
let's
jump
back
and
forth
view
registry.
D
Auto
configuration
so
jack.
My
opinion
on
this
is
that
metrics
are
so
incredibly
unstable
right
now
that
building
any
sort
of
auto
configuration
for
it
is
just
going
to
be
a
waste
of
time
that
we're
going
to
have
to
completely
rewrite.
E
Yeah
yeah,
I
figured
that
might
be
the
case,
and
so
I
just
wanted
to
like
confirm
that
you
know
basically
put
this
on
the
shelf
for
now
until
metrics
stabilize
so
that
that's
reasonable
to
me.
There's
still
like
a
route
to
configure
it
with
the
spi
and
it's
unstable
form,
and
once
it
stabilizes
we
can
address
it.
D
G
D
I
mean
this
also.
This
does
bring
up
a
kind
of
parallel
question,
which
is
right.
Now
we
can't
stabilize
auto
configuration
module
in
because
it
has
metrics
in
it
and
should
we
split
auto
configuration
like
the
metrics
auto
configuration
out
into
an
unstable
sub
module
honorable,
and
I
have
chatted
a
little
bit
about
it
and
we're
both
a
little
we're
a
little
tired
of
the
giant
proliferation
of
modules,
with
metrics
having
to
be
split
out
already,
but
depending
on
how
important
making
auto
configuration
stable
is
to
users
and
vendors.
A
Please
auto
oh
yeah,
I
was
gonna,
ask
have
we
have
we
had
user
any
user
pushback
on
it
being
not
stable.
D
D
Well,
I
mean
I,
I
think
at
least
the
splunk
agent
doesn't
use
any
metrics,
so
wouldn't
be
an
issue
for
us,
but
it
might
be
an
issue
for
the
main
agent
yeah.
D
D
D
A
Cool
who
added
this
one
and
you
wanna.
That's
me
all
right
so.
D
The
thread
local
random,
on
android
as
I've
noted,
is
totally
broken
in
almost
all
android
versions
and
it
always
initializes
with
exactly
the
same
seed,
which
means
if
you
use
the
sdk
on
android.
Without
configuring,
writing
your
own
id
generator.
You
get
the
same,
trace,
ids
and
span
ids
every
time.
You
start
up
a
new
instance
of
the
app.
D
It's
completely
broken,
so
I
thought
that
this
is
something
that
had
been
addressed
on
android,
but
I
was
goofing
around
with
it
this
week
and
even
on
like
android
api
level,
21,
it
still
is
totally
broken
so,
which
is
the
android
level.
21
is
what
we
target
with
the
sdk
in
the
api.
D
It's
kind
of
the
minimum
android
version,
but
I
mean
I'm
not
sure
how
to
address
this,
because
we
could
revert
our
random
ig
generator,
that's
in
the
sdk
and
make
it
go
back
to
using
regular
thread
locals
with
the
storing
a
random
in
it
or
we
could
provide
a
new
android
random
id
generator,
or
I
mean
I
just
don't,
or
we
just
document
that
hey
this
is
totally
broken
on
android.
You
need
to
write
your
own,
I'm
not!
I
don't
know
what
the
what
the
right
answer
is.
A
D
Fyi
we
used
to
have
the
implementation
they
used
throughout
local
blood
plus
random,
when
we
were
targeting
an
early
version
of
earlier
version
of
android,
and
then
we
thought
that
it
had
been
fixed
with
21,
but
it
was
not
so
we
could
go
back
to
that
or
we
could
just
document
that
it
doesn't
work
on
android.
I
don't
know
where
that
documentation
would
live
because
it
needs
to
shout
pretty
loudly.
D
A
E
D
Yeah,
so
we
could
probably
pick
some
arbitrary,
random
or
arbitrary
android
class.
That's
always
there
and
pretty
much
every
version
of
android
and
swap
out
the
id
generator.
I
don't
know
where
we
would
do
that.
We
do
that
in
the
sdk
and
auto
I
mean
I
just
anyway
where
to
do
it
is
not
clear
either.
A
Yeah
android
is
a
tricky
one
for
us
to
support,
always
still
I'm
looking
for.
If
anybody
knows
android
experts
that
are
interested
in
tracing
and
open
telemetry
send
them
our
way.
Please
well.
D
I
am
actually
actively
spending
most
of
my
non-directly
open,
telemetry
time
trying
to
get
up
to
speed.
Oh.
B
D
So
I'm
hoping
to
be
that
person
eventually
I'm
going
through
a
lot
of
android
tutorials
and
playing
around
with
things
and
hooking
up
the
sdk
and
seeing
what
happens,
and
so
that's
how
I
that's
how
I
kind
of
ran
across
this,
because
I
was
testing
things
pointing
at
a
local,
a
local
tracing
installation,
and
it
was
like.
Why
am
I
not
seeing
any
of
my
traces
from
this
last
time?
I
started
the
app
and
it
turned
out
that
I
like
searched
for
a
trace
id
that
was
in
the
logs.
D
A
D
G
D
I
don't
know
if
I
don't
know
if
I
have
anything,
that's
really
demoable
yet,
but
it's
also
really
interesting.
I
mean
it's
just
though
the
whole
way
that
android
works
is
just
different
than
a
regular
vm,
so
like,
for
example,
on
modern
android.
You
explicitly
cannot
do
any
io
on
the
main
thread,
which
is
good,
but
it
also
means
that,
like
it
crashes,
the
app,
if
you
try
to
so
there's
very
interesting
things
like
that,
like
you
really
are
super
restricted
on
what
you
can
do
where
inside
the
runtime.
D
A
Let's
see
other
things,
oh
yeah
we've
been
moving,
some
of
the
instrumentations
kind
of
calling
them
internal
because
they're
like
we're
basically
required
for
smooth
working
of
the
agent,
they
don't
really
produce
any
telemetry
or
propagate
context.
That's
just
things
to
work
around
bugs
in
how
the
whole
class
loader
stuff
works
primarily.
A
Fixing
tests
oh
yeah,
more
jax,
rs
instrumentation,
so
now
this
pulls
in
the
like
kind
of
how
we
put
the
context
path.
The
servlet
context,
path
at
the
beginning
of
the
span
names
so
now
also
does
that
with
the
jax
rs
application
path,.
A
Oh
yeah
mateusz,
you
want.
B
B
So
when
I
was
writing
the
whole
writing
instrumentation
module
doc.
I
kind
of
noticed
that
I
think
you
noticed
to
trust
that
we
have
in
in
the
instrumentation
module,
because
we
have
two
methods
that
are
doing
exactly
the
same
thing.
B
So
one
is
called,
is
helper,
module
is
a,
and
this
is
basically
no
it's
it's
helper
class
yeah,
it's
called
the
class
and
it's
a
just,
a
simple
predicate
function
and
the
other
was
called
additional
helper
classes
and
it
returned
an
array
of
class
names
that
were
supposed
to
be
treated
as
helpers,
and
this
one
completely
supersedes
the
additional
helper
classes
method.
So
I
removed-
or
maybe
maybe
you
removed
all
the
all
the
remaining
users
task
and
I
just
duplicated
the
method
as
it
will
be
removed
in
hopefully,
next
minor
race.
A
Cool
yeah,
this
is
so
this
takes
advantage
of
the
auto.
The
new
muzzle
feature
that
auto
finds
all
the
helper
classes
instead
of
before
we
had
to
list
them
all
manually
and
it
was
constantly
breaking
muzzle.
G
A
G
B
We
actually
sort
older,
separate
classes
according
to
well,
maybe
not
the
users,
but
according
to
inheritance,
so
we've
I've
actually
implemented
the
simple
graph,
topology
sort
algorithm
taken
from
wikipedia
and
and
it
works.
B
A
Oh
yes,
what
I
haven't
started
doing.
I
need
to
start
sending
the
weekly
updates
to
the
changelog.
The
way
john
is
doing
in
the
sdk
repo.
A
A
This
yes
suppressing
suppressing
yeah,
so
we
finally
have
this
documentation
here
this.
There
was
a
bit
that
to
do
here
in
this
whole
table,
so.
A
A
Oh
john,
maybe
we
could
chat
briefly
about
the
the
span
attribute,
annotation
that
he
proposed
in
the
sdk.
Do
you
want
me
to
do
to
rant.
D
Yeah
I
mean
it
has
not
been
approved.
I
don't
approve
of
such
nonsense.
A
Yeah,
I
think
you
updated
the
name
to
spam,
attribute.
D
D
D
D
A
A
lot
of
open,
prs
I'll,
try
to
get
check
in
on
those
later
today,
any
other
anything
else
anybody
thought
about.
In
the
meantime,
I
want
to
chat
about.
D
Now
why
don't
we
add
an
expression
language
that
you
can
put
in
your
annotations,
that
will
let
you
programmatically
write
some
and
write
some
java
or
some
groovy
code
inside
your
annotations.
That
sounds
like
a
good
idea.