►
From YouTube: 2021-06-15 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
B
I'm
literally
in
the
hot
spot
of
north
america
everything's
closed
everything's
shut.
They
just
recently
said
you
can
go
in
another
person's
backyard.
Damn.
A
Yeah
yeah
it's,
it
was
a
nerve-wracking
trip
for
me.
C
A
So
I
wonder
who
watches
this
anyway?
So
it's
this
is
this
is,
I
think,
more
of
like
an
archaeological
thing,
so
that
google
can-
or
you
know
they
can
do
some
like
face
recognition
and
then
eventually
do
a
deep
fake
of
me
teaching
about
open
telemetry.
I
don't
know
who
knows
the
like.
Our
state
doesn't
have
very
high
numbers
for
vaccination
rates.
B
Yeah,
that's
what
it
was
like
when
I
I
came
back
here.
It
was.
We
came
from
ottawa
to
winnipeg.
Ottawa
was
like
in
like
heavy
lockdown,
and
mass
restrictions
were
already
there
early
and
like
it
was.
You
could
really
feel
it.
You
know.
Even
people
were
scared
and
then
we
came
back
to
winnipeg,
which
is
like
nobody
goes
to
winnipeg
right.
So
there
was
like
one
case
and
everybody's
just
going
about
their
business
like
stuff's
still
open.
B
A
B
So
it's
like
my
my
people,
like
my
immediate
circles,
like
everybody's,
got
their
first
round
of
most
of
the
parents
have
their
second,
so,
like.
B
B
A
Yeah
yeah
I
was
like
I
was
amazed
like
new
york,
has
done
a
better
job
than
most
places.
I
think
and
like
I
was
watching
a
baseball
game.
A
The
stadium
is
filled
and
one
of
my
friends
was
at
the
game
and
I'm
asking
mom
like
you're
there
in
person
like
seriously,
and
he
said
yes,
they
actually
have
like
a
section
dedicated
just
to
vaccinated
people
who
are
fully
vaccinated.
You
show
your
you
show
your
card
and
you're
in
that
section
and
I'm,
like
that's
pretty
amazing,
pretty
good
numbers
there
in
new
york,
hey
it's
the
rest
of
the
gang.
A
Oh,
I
see
rob
kidd
out
here,
branding
the
austin
yeti
mug.
C
You
have
the
you
have
the
tankard,
I
have
merely
the
pint.
A
Oh
yeah,
but
I
swear
this
is
just
water
folks
on
youtube.
A
F
A
I'm
glad
you're
safe
for
now.
Yes,
for
now,
I'm
trying
to
not
get
delta
variant
at
all.
D
Okay,
so
I
did
not
attend
the
spec
sig
meetings,
so
I
don't
have
the
fancy
update
that
matt
usually
provides.
I
did
happen
to
be
looking
through
the
spec
repo
and
some
of
the
new
issues
recently
on
upr's
there's
an
interesting
thing
that
came
up
that
I
linked
to
rob
and
I
will
try
to
find
there's
an
interesting
proposal
for
an
instrumentation
api
that
showed
up
this
morning.
Oh
look
at
that,
so
rob's
already
so
yeah.
D
The
problem
that
it's
trying
to
address
is
providing
a
high
level
api
for
first
party
instrumentation
authors,
primarily
where,
instead
of
requiring
instrumentation
authors
to
know
all
the
minutia
of
semantic
conventions
and
so
forth,
and
have
to
think
about
okay,
how
do
I
like
pass
around
context?
How
do
I
do
all
these
things?
D
You,
like
the
instrumentation
api,
effectively
provides
a
a
start
and
end
function
that
you
call
and
it
it
then
has
all
these
callbacks
that
supply
information.
So
it
you
give
it
a.
Let's
say
it's
an
http
request
that
you're
trying
to
instrument
you
give
it
the
http
request,
object
and
you
you
know.
D
As
a
library
author,
you,
you
supply
these
extractors,
so
you
just
have
to
implement
a
bunch
of
functions
in
an
interface
or
a
bunch
of
methods
in
an
interface
that
extract
certain
information
out
of
whatever
object
you
passed
in,
so
you
pass
in
a
request,
object
and
then
the
extractor
will
say
you
know
get
me
the
http
method
from
this
opaque
thing
that
you
just
gave
me
right
or
get
me
the
response
code
from
this
opaque
thing
that
you
just
gave
me
it's
it's
interesting.
D
It
is
trying
to
solve
a
similar
problem
that
I
think
I've
spoken
about
here
or
maybe
in
a
github
discussion,
or
maybe
I
just
spoke
with
rob,
or
maybe
it
was
just
in
my
head.
I'm
not
sure
I
think
I
at
least
spoke
with
rob
about
it,
but
where
it
would
be
helpful
to
have
semantic
convention
help
us
where
the
you
have
a
method.
You
call
that
returns
a
bunch
of
like
return
to
populated,
attribute
hash,
and
the
signature
of
that
method
tells
you
all
the
things
that
you
need
to
supply.
D
So
it
tells
you,
you
know,
has
required
arguments
and
has
optional
arguments
and
the
required
arguments
would
be
things
like
you
know,
http
method
and
so
forth,
and
then
that
that
becomes
the
entry
point
for
instrumentation
authors
so
that
you
start
a
span.
You
call
this
helper
and
give
me
the
attribute
hash
and
then
that's
all
populated
with
the
semantic
inventions
and
away
you
go
this
instrumentation
proposal
here.
D
Instrumentation
api
proposal
is
more
heavyweight
and
it's
kind
of
flipping
things
around
and
and
just
having
these
start
and
end
hooks
that
you
call,
but
then
instrumentation
or
sorry
library,
authors
have
to
provide
these
extractor
mapping
things
so
anyway.
That's
my
summary
of
the
proposal
feel
free
to
read
the
large
amount
of
text
there
and
see
if
you
have
any
feelings
about
it.
My
personal
thing
is:
this
is
pretty
heavyweight
it's
kind
of
documenting
and
a
prototype
that
was
written
in
java,
so
it's
very
java-esque
yeah.
F
So
I
will
read
it
and
comment
on
it.
Perhaps.
B
Sorry
I
dropped
it
in
the
ruby
channel
for
the
hotel,
ruby
channel.
C
And
I
just
dropped
it
in
the
meeting
notes.
I
like
the
idea
of
a
struct
or
something
that
tells
you
like
I'm
about
to
make
a
span.
That's
an
http
span.
What
fields
ought
to
be
on
it
and
what
are
the
names
of
those
fields
but
yeah?
I
haven't
read
this
and
the
heavier
weight
and
more
influenced
by
java.
It
is
the
harder
it
will
be
for
us.
F
But
also,
it
feels
like
it's
extremely.
It
feels
like
it's
solving
a
problem
specifically
for
things
that
are
oriented
around
http,
like
requests
that
have
a
very
clearly
defined
request
and
response
cycle,
and
I
don't
know
if
that
I
feel
like
that
leaves
a
lot
of
other
things
out
in
the
cold.
That
might
want
to
be
instrumented
and
doesn't
really
do
much
to
solve
their
problems,
but
I'm
not
sure
yeah.
How
many
other
things
have.
E
I
wonder:
what's
the
like,
I
know
spring
cloud,
sleuth
is
maybe
one
there's
a
few.
You
know
like
first
party
libraries
that
have
done.
You
know
work
already.
I
I
wonder
who's.
Is
there
a?
Is
the
person
driving
this
a
first
party
library,
author.
B
E
Do
we
have
feedback?
I
wonder
if
we
should
we're
not
waiting,
it
would
be
folks
who
you
know
maintain
your
tips
should
be
getting
feedback
from.
You
know,
instead
of
getting
feedback
from
actual
library.
Authors
should
be
interested
in
doing
this,
instead
of
maybe
like
guessing
what
they
want.
Yeah.
B
I've
done
some
first
first-party
instrumentation
stuff
internally.
That's
like
I
was
alluding
on
that
thread
in
the
hotel,
ruby
channel.
Like
my
opinions,
changed
a
little
bit.
We
should
be
encouraging
people
to
only
depend
on
the
api
and
keeping
it
as
simple
as
possible
and
with
the
tracer
provider,
upgrade
change.
It
really
simplifies.
A
Everything,
okay,
I
I
can
see
the
idioms
of
using
the
builder
pattern
here
very
familiar
to
at
least
a
c
sharp
and
net
flavored
languages,
I'm
sorry
java
and
c-sharp
very
idiomatic.
A
B
So
we
don't
typically
need
the
explicit
start,
and
I
know
that's
not
always
the
case,
and
I
think
we
do
need
better
support
for
like
the
disconnected
start
and
ends,
but
also
like
that
extractor
and
having
that
as
a
formalized
is
something
that
instrumentation
library
authors
need
to
implement
themselves.
B
I
think
it's
just
adding
another
layer
to
some
of
the
things
we're
already
doing
I'll
deal
with
a
little
bit
more
structure.
I
think
the
pr
that
christopher
holmes
put
up
is
pushing
more
in
the
direction
that
I
think
we'd
like
to
go
is
where
say:
you're
instrumenting,
an
http
library
grab
yourself
a
uri
and
put
it
in
this
helper
and
you
get
everything
you
need
out
of
it
and
you
don't
really
have
to
think
about
it
and
you
don't
have
to
be
familiar
with
the
spec
and
we
can
update
it.
B
And
if
the
spec
changes,
we
can
have
updated
one
place
and
it
provides
a
lot
of
value
there,
whereas
the
this
otep
seems
to
propose
a
bit
of
the
opposite.
It's
like
no,
you
have
to
be
familiar
with
it
and
you
have
to
about
this
extractor
and
it
just
it's
pushing
more
work,
whereas
I
think
we
want
people
to
be
able
to
contribute
instrumentation
as
easily
as
possible.
A
So
how
do
we
want
to
capture
those
ideas
and
give
that
feedback
in
this
ulta
pr.
A
Robert
your
microphone
cut
out.
I
think.
A
A
Okay,
I
can
certainly
do
that.
Do
you
all
want
to
kind
of
brainstorm
in
a
document
or
a
gist,
or
something
and
or
even
just
in
slack
and
collect
these
write
these
down?
I
can
coalesce
them
and
try
to
make
it
a
little
more
diplomatic.
B
Yeah,
I
think
we
could
maybe
yeah.
We
could
probably
go
off
like
thread
off
of
my
post
and
the
slack
there,
and
we
can
just
leave
our
own
general
thoughts
and
ideas.
We
can
discuss
a
little
bit
a
little
bit
more
freely
and
then
structure
and
come
back
to
the
actual
otep
and
leave
some
comments
there
and
I
think
it'd
probably
be
even
a
little
bit
of
value
like
they
point
to
some
of
the
stuff
they've
already
implemented.
B
B
D
What
else
do
we
want
to
talk
about?
We
have
a.
We
have
a
bunch
of
refactorings
that
went
in
this
week
and
I
think
late
last
week
as
part
of
kind
of
a
response
to
the
review
from
the
tc
there's
a
few
more
open
issues
there.
Maybe
I
can
share
some
stuff
that
might
be
easier
than
just
talking
about
it.
Thank
you.
D
Okay,
so
let
me
go
to
the
issues.
First,
I've
gone
ahead
and
labeled
feedback
from
carlos
from
the
the
tc
with
spec
compliance.
It's
not
really
compliant
since,
in
the
sense
that
most
of
these
are
suggestions,
but
I
think
they're,
pretty
good
suggestions.
It
was
actually
really
good
feedback
that
we
got
from
carlos.
It's
pretty
thorough
I've
reached
out
to
him
and
asked
him
if
he
could
take
another
look
once
we've
addressed
all
his
his
current
feedback.
D
The
a
lot
of
the
things
a
lot
of
the
refactorings
that
happened.
Let
me
just
flip
over
here
closed
a
lot
of
the
refactorings
we're
getting
rid
of
some
of
the
things
like
no
op,
where
some
things
existed,
only
as
documentation
for
duct
types
and
instead,
we've
made
those
more
clearly.
D
You
know
the
duct
type,
so
no
op
span
processor
is
now
like
span
processor.
No
ops
fan
exporter
is
now
span
exporter.
D
D
Those
are
the
big
ones
that
I
can
think
of
right
now,
so
the
corresponding
issues
that
were
closed
are
these
spec
compliance
issues.
Here.
D
So
that's
quite
a
bit
of
breaking
now.
Quite
a
few
breaking
changes
that
have
gone
in.
We
haven't
done
an
rc2
release,
so
we
should
probably
do
an
rc2
release
with
some
of
these
things
in
them.
A
Is
so
for
the
rest
of
them
that
are
open?
Can
we
take
a
look
at
them
briefly,
yep
and
all
of
these
are
looking
to
be
included
in
the
milestone.
Are
these
all
blockers?
Sorry
for
the
for
the
version
1.0
release
do
are
any
of
these
blocking
that
would
prevent
us
or
if
they
did
not
make
it.
B
D
The
first
one
is
actually
we've
had
this
multi-span
exporter
sitting
around
for
a
while.
It's
not
actually
used
anywhere,
it's
just
there,
because
I
think
there
was
a
multi-span
exporter
in
the
java
sdk
way
back
when
and
we
effectively
ported
that
over
to
ruby.
So
it's
just
it
doesn't
appear
to
be
necessary.
D
I
have
a
pr
that
removes
that
multi-span
processor
was
an
a
premature
optimization,
so
I
have
prematurely
de-optimized
that
in
my
pr,
so
that's
this
pr
for
folks
are
interested.
This
just
removes
the
multi-span
things
so
I'll
commit
that
after
this
or
merge
that,
after
this.
A
It
looks
like
robert's
on
that
one
right,
robert's.
D
A
D
Yeah
it
it's
a
trivial
thing
that
I
think
the
spec
recommends
that
if
again,
this
was
a
fairly
late
change
in
the
spec.
The
spec
recommends
that
if
somebody
passes
an
empty
string
to
tracer
provided
or
tracer,
then
a
a
message
should
be
logged,
and
then
we
just
turn
that
into
a
default
tracer
of
some
kind.
D
We
actually
need
to
do
a
little
investigation
to
make
sure
that
we're
doing
the
right
thing
with
baggage
when
there's
empty,
when
the
baggage
is
empty,
so
in
particular
we
shouldn't
be
storing
it
in
the
context
we
shouldn't
be
storing
empty
baggage
in
the
context
or
propagating
empty
baggage.
You
should
just
omit
the
header.
D
We
have
this
in
the
api,
it's
used
in
two
places
in
the
api
and
then
it's
used
in
one
place
in
the
sdk
when
we
want
to
provide
a
default
text.
Map
text
map
propagator,
if
the
one
that
was
configured
is
either
not
available
or
there
was
nothing
configured
we
just
want
to
plug
in
some
default,
and
so
we,
the
default
that
we
plug
in,
is
the
no
op
that
the
the
api
provides.
D
So
there's
no
spec
requirement
to
expose
this.
No
op
text
map
propagator,
it's
just
supposed
to
be
a
private
thing,
it's
only
public
so
that
the
sdk
can
use
it,
and
it's
also
public
because
of
it's
kind
of
hard
to
hide
classes
that
are
used
in
like
used
outside
of
the
hierarchy
like
containment
hierarchy,
I
guess
in
in
ruby.
D
So
that's
why
it's
exposed.
So
we
need
to
do
some
wrangling
of
things
to
like
decouple
the
sdk
and
api
here
and
to
hide
this
no
text
map
propagator.
So
it's
just
a
bit
of
fiddly
work.
D
Yep
maybe
anyway,
if
somebody
wants
to
like
jump
on
this
refactoring,
please
feel
free.
It's
going
to
be
a
fun
little
bit
of
coding,
there's
probably
either
duplication,
that's
needed
between
the
sdk
and
the
api,
or
I
don't
know.
D
Okay,
yeah.
A
E
E
I
know
I'm
like
I.
I
think
I
got
the
green
light
in
q3
to
work
on
this
closer
to
full
time
from
people
more
important
than
me
in
my
company
wheat.
So
nothing
yeah,
no
promises
yet,
but
I
think
it's
going
that
way
so
yeah
I
can
contribute
more.
But
okay,
I
don't
know
I
heard
contribution.
I
know
I'm
the
least
contribution
person
here.
E
Just
give
me
the
baggage
one
that
one's
easy-
and
I
owe
the
helpers
general
I'm
about
to
take
a
day
this
week,
so
I'll
do
the
bag
that
feels.
B
E
F
E
B
B
Even
if
we
had
all
these
done,
I
would
still
like
to
see
it
come
out
as
a
second
always
candidate
yep,
just
just
because
we
want
to
flush
out
as
much
there's
stuff.
That's
not
related
to
the
spec
compliance
at
all
that
I've
been
that's
been
popping
up
internally,
as
applications
are
more
adopting
internally
at
shopify,
and
it
would
be
nice
to
just
like
get
this
thing
as
stable
as
possible
before
we
do.
The
beautiful
1.0.
B
D
Yeah
like
if
I
look
at
the
oz.
D
D
Yeah,
I
think
this
was
probably
the
rc
release
at
least
37
gems
and
two
gems,
so
yeah
we've
had
like
close
to
30.,
I
think
close
to
30
pr's
go
in
since
then.
D
So
that's
a
lot
of
work
that
is
on
head.
That
is
not
released,
so
I
think
we're
overdue
for
an
rc2
release
and
we
should
just
do
that
with
whatever
we
have
on
head
at
the
moment,
and
then
we
can
always
follow
it
up
with
an
rc
3
release
later
on.
B
D
Cool
okay,
changing
streams,
a
little
bit
open,
pull
requests,
there's
a
few
things
that
have
been
sitting
open
for
a
while,
and
we
should
probably
push
along
a
bit.
D
D
These
two
are
related,
the
update
context,
match
spec
and
the
active
support
notifications
thing.
This
was
motivated
by
this
one
and
will
help
I
think,
structure
the
code
a
little
bit
better.
F
And
I'll
revisit
it
once
the
context
stuff
is
finished,
it's
not
blocking
us
or
anything
internally
like
we
don't
need
it
at
the
moment.
Incredibly
much
so
I'll
revisit
as
soon
as
robert's
done
with
the
contact
stuff.
D
The
monotonic
clock
is,
it
doesn't
need
to
block
like
we.
We
explicitly
made
a
change
earlier
on.
There
was
a
a
change
to
the
exporter
api,
I
guess-
or
the
span
data
api,
so
so
that
we
could
do
this
later
on.
So
this
monotonic
clock
thing,
I
will
try
to
pick
up
again,
but
probably
not
before
next
week.
D
At
this
point,
the
main
piece
of
work
that
is
required
there
other
than
you
know,
testing-
is.
D
This
corner
case
of
starting
a
span
with
an
explicit
start
time
stamp
and
then
having
the
end
time
stamp,
be
relative
to
the
start
time
in
some
way
yeah.
I
won't
go
through
the
whole
description
again,
but
the
reasoning
is
complex.
I
think
we
should
do
it,
so
I
will
do
it
and
then
people
can
argue
against
me
if
they
want
in
the
pr.
D
And
then
we
have
a
bunch
of
open
stuff
from
other
contributors,
so
the
manticore
instrumentation
it
looks
like
there
hasn't
been
any
progress
on
this.
B
I
am
going
to
review
there
and
said
I'd.
Do
it
a
while
ago
and
haven't,
I
think,
there's
there's,
there's
some
kind
of
approaches
that
aren't
quite
aligned
with
how
we've
been
doing
instrumentation.
So
I
think,
there's
going
to
be
some
substantial
changes,
since
you
suggested
there.
I
think
they're
using
method,
aliasing
and
a
few
other
things
that
just
don't
really
fit
with
kind
of
the
convention
week.
B
That's
as
I
mentioned
before,
the
code
in
the
code
base
should
look
like
it
came
from
one
person
and
not
multiple,
and
this
would
definitely
deviate
quite
a
bit
from
what
we've
been
doing.
So
I
just
need
to
set
aside
a
little
bit
of
time
to
go
through
and
actually
look
at
what
banticore
is
and
if
there's
some
really
valid
reasons
of
why
that
approach
was
taken.
But
I
suspect
that
there'll
just
be
some.
D
Okay,
chris
holmes
had
this
utility
for
http
http,
request
attributes.
I
think
this
may
be
blocked
on
yeah
yep.
D
It's
blocked
by.
Let
me
roll
the
dice
yeah
okay,
active
job
instrumentation.
What's
the
current
status
of
that
one?
Is
that
just
waiting
for
reviews
yeah?
I
think
it's.
F
Ready
to
go
otherwise
I'm
trying
to
remember
if
there
was
anything
well
well
now,
there's
version
conflicts.
I
guess
I'll
fix
that
real
quick,
but
that's
probably
just
from
it
sitting
for
a
while
yeah
they're,
pretty
yeah.
I
don't
think
there's
anything
that
was
needed
other
than
people
to
say
yes,
so
yeah.
If
anyone
wants
to
review
it
later,
that'd
be
great
cool
yeah.
B
D
So
elasticsearch
instrumentation
was
super
active
a
while
back
and
then
I
don't
think,
we've
okay.
So
this
is
just
waiting
for
miguel
to
update
the
pr
based
on
the
feedback
we've
provided.
So
there's
no
real
action
for
us
there.
I
can
poke
him
in
the
cncf
slack
for
an
update,
he's
pretty
responsive
there.
B
I
want
to
finish
it.
That's
the
short
answer,
the
some
of
the
internal
like
stuff,
I'm
doing
on
the
inside
of
shopify,
I'd
like
to
see
done
first
and
then
give
rails
some
really
concerted
attention.
I
think
that
andrew's
done
some
good
stuff
and
some
good
stuff
coming
in
so
I'd
like
to
build
on
that.
I
just
want
to
have
some
dedicated
time
on
that
and
just
get
really
immersed
in
it.
So
I
like
to
let
it
linger
for
probably
another
couple
weeks
if
it's
not
causing
anyone,
anguish,.
D
Not
really,
okay
and
then
I
think
these
two
are
stale.
I
need
to
go
back
and
verify
this
was
attempting
to
fix
something
that
was
fixed,
a
different
way
with
the
jaeger
exporter.
I
just
want
to
verify
that
this
is
this
case.
Won't
actually
happen
anymore,
and
then
we
can
just
close
that.
D
Close
ipr
yeah-
this
is
really
really
old
at
this
point,
so.
D
And
then
the
grpc
example
is
even
older.
Does.
F
Does
anyone
consider
themselves
proficient
with
grpc,
because
I
could
take
this
on
if
people,
if
nobody
else
feels
like
they
would
be
good
at
it,
but
I
don't
know
that
I
would
consider
myself
proficient
more
just
that
I've
stared
at
it
long
enough
and
have
kind
of
an
idea
of
what
to
do,
but
I
was
wanted
to
see
if
anyone
else
felt
like
they
would
be
a
better
fit
for
it.
B
Like
if
you
did
it,
I
I
know
we
need
it,
because
I
I
am
willing
to
fall
on
that
sword
if
necessary
and
familiarize
myself
with,
because
there's
a
couple
teams
that
are
using
internally
and
I
would
like
to
add
some
formal
support
for
it.
So
it's
something
that's
on
my
ever
growing
to
do.
But
if
you
do
have
some
experience
and
it's
not
completely
cryptic
to
you,
then
maybe
that
might
be
nice
and
this
is
and.
D
Yeah
so
there's
this
is
just
example
code,
so
just
some
documentation
for
how
would
you
instrument
grpc,
there's
a
separate
thing
which
is
grpc
instrumentation
and
then
there's
the
otlp
over
grpc.
D
I'm
not
familiar
with
the
apis
in
ruby
for
grpc,
which
is
why
I
haven't
paid
too
much
attention
to
this
they're,
not
fun,
but
they're.
F
Decent
okay,
they
there's
there's
this
concept
of
an
interceptor
in
the
ruby
light.
Well,
I
think
it
might
actually
be
in.
F
I'll
take
a
stab
at
it.
I
I've
written
one
before
so
I'll,
see
what
I
can
do.
A
It's
it
follows,
I
don't
know
it's
essentially
just
like
rack
middleware,
those
interceptors.
What's
what
stinks
is
that
the
the
the
apis
themselves
are
like
very
obtuse,
but
where
I
used
to
work,
it
was
something
that
we
used
all
the
time.
Let
me
see
if
I
could
share
something
helpful.
B
I
have
a
pr
up
for
the
context,
refactoring
and
I
think
it's
ready
for
people
to
look
at.
I
believe
I've
addressed
all
the
feedback
so
far.
D
C
D
It's
useful
to
keep
them
accurate,
so
that
needs
to.
F
Go
through
cycles
of
loving
github
labels
and
putting
them
on
everything
and
making
really
useful
schemes
out
of
them
and
then
completely
forgetting
about
them
for
months
at
a
time
and
then
coming
back
to
him
and
thinking
wow,
this
scheme
was
bad.
Why
did
I
do
it
this
way?
I
see
myself
in
this
picture.
D
Cool
yeah,
so
we
should
take
a
look
at
that.
Did
you
want
to
say
something
in
particular
about
gruff.
A
What
I
was
going
to
say
was
that,
because
it's
so
bare
bones
and
so
obtuse,
there
was
a
lot
of
stuff
that
was
written
to
deal
to
try
to
simplify
integrating
with
rails
in
particular,
and
you
might
be
able
to
dig
through
some
of
this
code
to
familiarize
to
help
you
familiarize
yourself
with
how
to
work
with
grpc
and
so
there's
a
stack
around
the
instrumentation
itself,
from
both
the
client
side
and
the
server
side.
B
A
F
And
I've
seen
gruff
and
there's
another
framework
that
came
out
recently
for
well
recently
several
years
ago,
similar
to
graph,
I
can't
think
of
the
name
of
it,
but
it
kind
of
was
a
similar
idea.
Wrapped
a
lot
of
the
bad
parts
of
the
ruby
grpc
experience
up
a
little
bit
made
it
nicer.
A
B
A
B
D
Yeah
this
issue
is
really
interesting,
so
some
redis
exceptions
are
not
errors.
We
have
tried
to
instrument
redis
at
the
the
lowest
level,
which
is
arguably
the
correct
thing
to
do.
But
when
redis
clustering
comes
into
play,
it
is
not
because
basically
redis
clustering
is
layered.
On
top
of
redis
rb,
I
mean
it's
part
of
red
srb,
but
it's
like
an
optional
thing
that
gets
layered
on
top
and
it
does
some
error
handling
internally,
where
well,
let's
just
like
jump
straight.
There's.
D
No,
it's
basically,
if
you
get
a
command
error
back
that
says
that
this
key
moved
to
a
different
server.
Then
you
deal
with
that
by
going
and
querying
that
other
server
instead,
I'm
so
issuing
the
request
to
the
the
other
server
with
you
know:
retry
account
limit
so
like
there's
moved
and
asked
are
the
the
two
interesting
responses
from
like
redis
clusters.
D
So
this
is
layered
on
top
of,
like
your
reddest
client,
and
the
problem
here
is
that
these
end
up
not
being
errors.
There's
there's
some
complexity
because
you
kind
of
want
each
each
request
to
each
of
the
different
servers
to
be
represented
as
independent
spans.
D
F
F
A
Is
it
or
is
this
a
thing
where
the
the
redis
cluster
should
be
instrumented
and
the
end
user
should
choose
which
one
to
use?
Because
it's
a
matter
of
the
volume
of
spans
or
you
know
you
know,
there's
other
things
that
we
can
do,
but
it
just
seems
like
you
either
all
want
all
the
details
or
you
don't.
D
Yeah,
so
there's
two
suggestions
here:
one
is
that
you
kind
of
have
a
clustering
mode,
and
if
you,
if
you
pass
in
the
clustering
option,
then
we
instrument
at
the
clustering
level
rather
than
at
the
client
level.
The
other
is
that
you
can
actually
instrument
at
both
but
be
aware
of
the
cluster,
like
the
the
higher
level
span
in
the
lower
level
instrumentation
and
based
on
the
presence
of
that
span.
You
either
augment
it
with
some
additional
information
or
you
create
a
new
span.
F
Kind
of
like
that
approach.
Actually,
if
we
know
that
there
is
a
higher
level
cluster
span,
then
we
can
say:
okay,
don't
flag
the
span
as
error
like
just
just
record
this
band
and
be
done
with
it,
and
the
higher
level
span
will
get
the
error
flagged
if
none
of
them
succeed
right.
Something
like
that.
D
I
don't
know
so
yeah.
I
don't
think
we
need
to
necessarily
come
up
with
solution
here,
but
it's
it's
an
interesting
problem
that
that
we
haven't
addressed
at
shopify,
we're
not
running
redis
clusters
in
this
way.
So
we're
not
encountering
this
problem.
A
F
A
D
D
D
So
really
the
only
options
for
instrumentation
are
either
not
to
set
it
not
to
set
the
status
at
all
or
to
set
it
to
error,
and
then
application
code,
which
supposedly
knows
more
about
the
exact
scenario,
is
supposed
to
be
the
only
thing
that
would
set
the
status
to
okay
and
clobbering
yeah.
That's.
A
F
F
A
I
would
say
that
this
pattern
is
going
to
apply
to
other
libraries
like
faraday,
where
we're
trying
to
do
retries
trying
to
use
back
offs
in
particular
where
we
start
seeing
like
that
wait
period
for
a
retry
to
occur
where
the
time
spent
like
how
do
we
represent
that,
as
like
I've
been
I'm
waiting
for
my
next
block?
Is
there
a
higher
level
span?
That's
like
here's
all
the
retries
and
then
there's
sorry.
This
is
the
amount
of
time
spent
for
the
entire
retry
and
then
here's
all
the
individual
retries.
E
It
would
be
the
data
dog
tracer
useful.
I
think
it
may
be
a
useful
concept
here,
where
I
guess
our
equivalent
of
like
in
span
as
a
you
know.
If
a
exception
gets
raised,
there's
a
default.
You
know
proc,
that's
just
like
sets
the
metadata
we
need,
but
you
can
also
for
most
giving
not
all
integrations.
I
think
it's
mostly
like
queue
and
some
other
ones.
E
Basically,
whatever
people
ask
for
whoever
it
was
an
outside
contributor,
let
you
pass
in
per
integration
like
a
proc
or
lambda,
where
you
can
define
your
own
error
handling,
so
you
can
override.
So
the
common
cases
like
there
was
a
lot
of
sidekick
things
that
are
technically
like
exceptions,
but
they're
expected,
and
you
know
that
job
is
retrying
four
or
five
times
anyway,
and
so
people
said
I
just
want
to
you
know
orbit.
You
know
passing
my
own
arbitrary
logic
here,
so
that
could
be
it.
E
E
B
F
The
rack
stuff
yeah.
Well,
I
mean,
if
you
have
advice,
I'm
sure
we'd
like
to
hear
it.
Essentially
the
the
rails
monolith
that
we
run
for
github.com
is
special
in
a
great
many
ways
and
we
found
it
very
difficult
to
get
the
rack
instrumentation
to
install
correctly
from
the
sdk
initialization
process
start
getting
fun
things
like.
Oh
the
you
know,
rack
middle,
where
stack's
frozen
and
I'm
like
it
shouldn't
be
it's
way
too
early
for
that
etc.
F
But
one
of
the
ways
we
thought
to
work
around
it
and
we
have
several
applications
that
are
actually
just
rack
applications
and
one
of
the
things
we
were
going
to
do
was
say:
okay,
we'll
just
use
the
rack
instrumentation
here
directly
in
the
you
know,
rack
up
file
and
what
we're
finding
and
what
I'm
still
finding
actually
is
that
those
spans
that
are
getting
created
from
the
the
rack
root
span
are
all
api
spans,
they're,
not
sdk
spans,
which
makes
sense
because
we
weren't
creating
an
instance
of
the
rack
instrumentation
and
then
calling
install
or
anything
we
just
kind
of
passed
the
class
to
the
rack
instrumentations
that
use
this.
A
F
B
That's
yeah,
there's
there's
two
parts
I
see
like
where
we're
setting
that
that
default
tracer.
I
don't
think
it's
we're
doing
it
right
like
it's
not
getting
upgraded.
If
the
install
clip
doesn't
get
called,
I
don't
know
if
we
want
to
change
that
behavior.
I
think
the
expectation
is
that
without
the
install
of
getting
called
it,
you
just
assume
that
it's
not
turned
on.
So
it
shouldn't
be
doing
anything
so
yeah
like
I'm
a
little
apprehensive
to
make
that
change.
B
F
B
B
I
I
do
have
rack
applications
at
shopify
as
well,
that
are
not
rails
and
the
way
we've
been
doing
it
is
not
through
the
config
ru.
It's
I
don't
even
know
what
the
series
is
called
then
spent
a
lot
of
time
with,
like
just
rack
applications,
but
you
just
you
add
the
line
like
use
and
then
you,
the
open,
telemetry
middleware
right,
I'm
not
in
the
config.
Are
you
and
I
haven't
had
any
issues,
but
I'm
assuming
that
the
github
monolith
probably
has
a
lot
more
complexity
than
the
applications.
I've
been
interacting
with.
A
B
F
A
Yeah,
I
don't.
I
don't
know
that
we
have
access
to
it
everywhere,
but
I
can
take
a.
A
If
we
can,
you
know,
I
think,
also
it's
like
the
placement
of
where
it
is
right.
Now
we
profile
our
existing
tracing
stack,
so
we
have
a
stack
prof,
middleware,
inserted
first
and
then
our
instrumentation,
our
trade
distributed
tracing
second,
so
that
our
our
profiles
include
trace
information,
because
that's
something
that's
interesting
to
us
right
now,.
A
Yeah,
as
so
my
boss
reminded
me,
is
55
000
requests
per
second
on
twitter.
I'm
like
thanks,
bud.
D
So
there's
a
couple
of
things
I
want
to
mention
one
is
that
the
the
upgradable
traces
won't
kick
in
here,
because
they
that's
an
internal
like
if
you're
explicitly
creating
a
tracer
the
way
we
are
here,
an
api
tracer.
That
is
not
an
upgradeable
tracer
it
it's
only
an
upgradeable
tracer
if
you
got
it
from
the
tracer
provider
and
we're
explicitly
not
wanting
an
upgradeable
tracer
in
this
case.
The
other
thing
is
that
the
change
that
was
made
related
to
samplers
and
not
creating
a
span.
D
That
change
is
going
to
affect
what
what
you
actually
see
here
previously.
We
would
have
created
spans.
D
There
were
api
spans
that
never
get
recorded,
but
have
their
own
span
id,
which
means
children
like
child
spans
end
up
like
if
a
child
span
is
a
real
span,
it
ends
up
disconnected
from
the
parents
and
that
problem
should
go
away
once
we
do
an
rc2
release.
So
we
that's
another
reason
to
get
that
out,
because
that's
actually
a
a
bug.
D
I
think
that
is
has
been
fixed
in
head
and
we
haven't
released
it
yet
so,
but
that
won't
directly
it'll
make
things
a
little
bit
better
for
you,
but
it
won't
make
them
all
the
way
better
because
you're
just
not
going
to
get
any
spans
in
your
traces
from
those
from
like
the
rack,
middleware,
so
yeah.
B
Okay,
yeah,
I
don't
think
I
have
any
like
particular
suggestions
to
your
problem
because,
like
it's
like
your
sdk
is
still
being
installed
right
and
you're
still
telling
it
to
use
rack
middleware
right
because,
like
you,
can
you
can
add
your
rack.
That
will
work
explicitly
like
you're
doing,
but
you
still
have
to
tell
the
sdk
install
hook
to
install
it
right.
Is
that
you.
F
Can
tell
me
no
as
best
we
can
tell
it's
getting
initialized,
I
can
see
it.
I
can
see
it
happening
in
the
rails,
logs
and
happily
saying
yeah
I'll
use
rack
that
sounds
great.
What's
actually
even
a
little
more
bizarre
is
that
our
health
checks
for
from
our
load
balancer
actually
do
get
traced
and
recorded
as
fans
completely
correctly
and
just
nothing
in
the
application.
So
it's
actually
even
weirder
when
you
start
looking
at
it,
but.
A
We're
gonna
try
to
reproduce
it
and
get
more
information
that
I
I
think
it
was
just
we
were.
We
were
curious
if
you
had
any
tips
and
that's
all
yeah.
F
F
Reason
I
know
that
is
I.
I
tried
to
wrap
one
of
the
controller
actions
in
a
just.
A
test
span,
a
hey
earth
test
and
inside
that
span
I
tried
to
log
a
bunch
of
details
to
it,
because
I
can't
actually
attach
to
these
running
processes
in
kubernetes
correctly,
like
it's
a
miserable
thing
and
what
I
started
getting
was
exceptions
telling
me
that
there
was
no
like
two
span:
data
method
on
the
span
object
and
that's
how
I
realized
we
were
actually
looking
at
api
spans,
because
there
should
have
been
that
method.
F
It
should
have
existed
and
that's
that's
kind
of
how
we
figured
it
out.
B
At
that
same
time,
are
you
able
to
because
you're
you're
saying
that
rails
console
works
at
that
same
time
like
when
you're?
Can
you
like
dump
out
the
status
of
the
instrumentation
yeah,
and
it's
like
see
if
it's
actually
like
when
it's
in
production
running
not
in
the
console?
If
it's,
it
is
actually
successfully
installing
it?
F
Something
is
that's
what
I
was
thinking
I
mean
I
I
started
trying
to
poke
around
with
like
unicorns
after
four
cooks
and
and
all
that
stuff
and
I'm
I
have
a.
I
have
this
like
sinking
feeling
that
maybe
that's
actually
where
the
problem
is
happening,
and
I
don't
something
about
that
is-
is
possibly
what's
going
wrong,
not
excited
about.
B
F
That
was
my
other
thought.
Was
that,
like
there's,
there's
a
it's
not
actually
getting,
it's
not
actually
doing
what
we
think.
F
It's
getting
installed
somewhere
and
not
in
other
places,
because
some
of
the
like
our
slash
status,
lol
rails
hook
or
whatever
that
like
is
our
load
balancer
status.
That
works
so
like
whatever
process
is
responding
to
those
got
upgraded,
but
somehow
everything
else
isn't.
I'm
not
sure
it's
a
little
bizarre
we're
digging
deep
into
the
parts
of
our
code
base
that,
like
nobody,
has
touched
in
ages
and
nobody
really
remembers
how
it
works.
B
Do
do
circle
back
if
you're
still
having
problems
and
like
or
definitely
let
us
know
when
you
identify
the
problem,
whether
it's
just
a
configuration
thing
or
not.
It's
interesting
to
see
what
happens
there.
F
D
A
Definitely
so
a
couple
things
that
we
can
do
is
that
we
can
check
what
that
instance
tracer
object
id,
so
we
can
see
if
it's
the
same
object
as
the
you
know,
api
tracer
before
it
was
initialized,
and
then
we
can
also
print
out
what
the
current
status
is
of
the
existing
global
tracer,
the
default,
a
tracer,
I'm
assuming
that
it'll
be
upgraded
at
that
point.
From
that
same
spot,
where
we
were
looking
android.
B
One
one
last
thing,
because
I
guess
it's
in
your
thick
are
you
because
I'm
wondering
if
the
example
like
that
you
just
linked
if
it's
working,
because
when
the
builder
is
calling
the
sdks
already
initialized,
I
don't
know.