►
From YouTube: 2021-06-01 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
A
Pretty
good,
pretty
good,
my
might
be
working
from
a
cabin
this
week
or
later
this
week
I
should
say.
A
Yeah
have
like
a
through
the
girlfriend,
her
family
as
a
cabin
and
their
neighbor
just
got
starter,
link
and
they're,
just
sharing
the
internet
with
them,
and
she
went
out
last
week
and
tested
it
out.
She
could
do
remote
meetings,
so
I'm
gonna
try
to
see
if
I
can
maximize
this.
This
advantage
for
the
rest
of
the
summer,
because
it's
like
a
cute
little
cabin
right
on
the
water.
C
Yeah
also
report
back
in
a
non-recorded
session,
your
experience
with
starlink,
and
then
I
certainly
don't
think.
C
Like
I
don't
want
to
impact
tesla's
stock
price
indirectly,
through
spacex,
indirectly
through
internet
providers,
right
right,
I
should
say
vis-a-vis
right
like
that's
the
fancy
way
to
say
that.
A
Yeah
I
was
just
like
this:
transition
to
remote
has
been
getting
substantially
better
every
year,
like
the
the
first
few
months
of
it,
I
was
in
a
500
square
foot
apartment
with
someone,
and
we
were
both
like
trying
to
do
full-time
whatever,
and
so
I
was
in
the
one
room
and
they
were
in
the
other
room
and
it
was
awful.
So
we
moved
back
to
like
our
home
city
and
now
we
have
our
own
offices
and
now
that
we're
here
we
have
access
to
family
cabins.
A
B
I'll
blame
you.
I
would
too,
if
it
kept
getting.
If
I
was
on
an
upward
trajectory
like
that,
I
I
wouldn't
mind
if
we
had
reasonable
internet,
my
family
has
a
less
of
a
cabin
more
of
a
vacation
house
on
on
the
water,
similarly
kind
of
out
in
the
middle
of
nowhere.
They
have
internet
now,
but
it's
not
really.
I
don't
think
I
could
do
any
kind
of
video
calls
on
it
or
anything.
If
I
could,
I
would
definitely
go
work
up
there.
A
B
B
A
Nice,
I
think
matt
said
he
wasn't
going
to
be
here
today
and
I
think
we
were
supposed
to
have
a
someone
else
was
going
to
pop
in
to
talk
about
something
someone
that
canada,
our
regular
someone
knew
was
going
to
come
in
or
something
like
that.
I
think
it
was
for
the
is
it
the
http
yeah
yeah
that
one
yeah.
D
Cool,
we
can
probably
get
started
it's
about
that
time.
I
don't
really
have
any
spec
updates,
because
I
rely
on
matt
for
that,
but
he
did
post
a
couple
of
interesting,
possibly
controversial
things.
D
Let's
see,
maybe
I
should
be
sharing
some
of
this
stuff.
Let
me
just
get
my
screen
organized.
B
B
E
D
D
I
think
this
has
been
open
for
a
while,
and
it's
been
like.
We've
certainly
discussed
it
for
a
while,
where
this
issue
is
that
you
end
up
with
instrumentation.
D
Let's
pick
an
example
like
faraday,
so
faraday
may
wrap
some
http
library
and
in
turn
it
may
be
used
by
as
an
example
the
koala
gem,
which
is
a
gem
for
accessing
facebook's
api
and
if
you
just
go
in
and
sort
of
instrument
at
each
of
these
levels,
logically
speaking,
they're
all
generating
client
spans
so
you'll
end
up
with
a
koala
client
span.
D
That
then
has
as
a
child
a
faraday
client
span,
and
then
that
has
as
a
child
a
an
http
library,
client
spam
and
on
the
other
side
you
know
you
may
have
something
like
rack
and
then
you
have
rails.
And
if
you
take
a
naive
approach,
you
may
end
up
creating
a
service
ban
at
the
rack
as
rack
middleware
and
then
another
server
span
for
rails.
D
So
in
like
action,
controller
metal
or
something
like
that,
so
the
way
we've
been
tackling
it
is
on
the
client
side
having
the
ability
to
actually
pass
tags
down
to
the
lowest
level
of
instrumentation.
So
the
lowest
level
of
instrumentation
would
be
the
http
client
library.
D
I
think
the
specs
suggest
I
haven't
dealt
with
it,
but
the
spec
kind
of
assumes
that
you're
going
to
have
these
pairs
of
client
and
service
fans
and
you're
going
to
have
potentially
some
way
on
the
back
end
of
us
like
relating
them
in
some
way
so
like
you,
might
want
to
look
at
the
difference
in
latency
of
the
client
and
server
spans
and
then
infer
that
that
is
queuing,
latency
well,
queuing,
delay
or
network
transport
delay.
D
There's,
I
guess,
ambiguity
in
the
spec
around
whether
it's
okay
in
sc
spans.
It's
been
an
open
issue
for
a
long
time.
There
is
this
proposal
from
john
watson
to
write
up
a
spec
change
that
actually
explicitly
allows
these
nested
clients
spans
or
nested
service
fans
to
get
the
issue
unstuck.
D
So
yeah,
that's
that's
what
this
is
about.
It's
controversial
because.
D
The
there's
been
a
long
running
argument
that
really
you
should
oh,
like
it's
probably
more
from
a
vendor
perspective,
because
you
need
to
do
more
processing
on
the
vendor
side,
to
figure
out
how
nested
service
spans
relate
and
how
nested
client
spans
relate,
and
you
know
forgiven
serviceman.
What's
the
canonical
clients,
man,
but
there's
been
pushback
for
a
while
that
really
you
should
have
logical
pairings
of
client
and
service
fans
yeah.
I
I
don't
know
what
the
discussion
was
around
this
in
the
spec
sig
meeting.
C
It's
one
of
those
things
where
it's
like
at
some
point:
there's
a
level
of
abstraction
that
we're
trying
to
correlate
these
things
with
right
and
my
my
two
cents
is:
the
vendor
should
be
the
one
that
should
offer
a
vendor
feature.
That's
like
this
is
what
I
designate
as
being
the
client
and
anything
else
marked
as
a
client's
band
under
it
is
like
an
internal
client
span,
you
know
and
they
should
just
be
ignored,
and
then
this
is
the
pair
that
meets
up
with
it.
C
I
mean
there's
so
many
of
these,
especially
in
other
languages.
So
many
of
these
hdb
client
libraries
at
what
point
do
we
say
like
this?
Is
the
entry
point
of
the
client.
If
we
wanted
to
make
a
capability
on
our
side
on
the
sdk
side,
they
say
like
hey
you
when
you
configure
auto
instrumentation.
A
C
Or
or
something
of
that
nature,
but
through
a
configuration,
but
even
then
it's
like
your
application
could
use
tons
of
different.
You
know
http
client,
libraries
mixed
in
because
of
legacy
or
whatever.
So
it's
like
you
know,
I
don't
know
this
feels
to
me
more
like
a
vendor
configuration
thing.
Speaking
of
I
got
two
vendors
here.
E
I
just
think
you
should
have
multiple
client
spans.
It's
not
a
big
deal
and
you're
just
never
going
to
be
able
to
handle
all
the
cases.
If
you
try
to
enforce
some
sort
of
like
one
client
thing,
because
you
also
don't
know
like
unless
you're
I
guess
you
could
do
sort
of
the
stuff
we
do
which
is
like
passing
stuff
down
and
checking
if
it
exists,
but
that
feels
hacky
and
there's
no
and
speaking
of
spec.
There's
no
spec
around
how
to
do
that.
So
everything
is
like
customized
and
not.
E
You
know
and
starts
to
you
know,
you're,
just
introducing
a
new
problem
and
yeah.
I
don't
know
stuff
like
like
elastic
or
aws
things
that
are
like
that,
implement
it's
http,
but
maybe
it's
like
a
database
span
over
http.
E
I
just
think
you'll
never
be
able
to
have
a
clear
specification
for
that
stuff.
B
If
the
maybe
it's
just,
the
specs
should
be
a
little
more
loose
right.
There
are
areas
of
the
spec
today
that
are
like
frustratingly
vague,
and
there
are
areas
like
here
that
seem
frustratingly
specific
and
almost
seem
to
cause
problems,
and
this
this
is
maybe
to
me
just
an
aspect
of
like
loosening
up
the
language.
To
say
this
parent
could
be
the
parent
or
this
span
could
be
the
parent
of
a
remote
service
man
or
should
be,
or
maybe
or
just
let
the
ambiguity
happen
and
provide
the
guidance.
B
F
Yeah,
the
channel
is
saying
that
our
company,
that
the
back
end
can
handle
it
just
if
this
whole
in
their
example
in
the
in
the
original
part
of
this
thread,
is
a
chain
of
a
jax,
rs,
hp,
client
with
an
apache,
http
client
and
then
tcp
stacks
opening
it
like
markimal's
client,
they're,
all
part
of
this
chain
of
creating
a
client
connection
to
a
server.
F
If
it
matters
where
you
find
a
pairing,
the
vendor
figures
out
how
to
find
which
parent
span
had
server
before
a
child's
band
turned
into
a
client
and
there
you
found
the
pairing
and
you
could
solve
it
with
queries
and
all
of
those
things
were
part
of
the
client
chain,
so
they're
all
they're
all
clients.
So
yeah,
that's
fine!
That's
fine!.
D
Yeah,
where
their
challenges
come
in
are
like,
if
they
type
not
this
spec,
I
think
you
probably
end
up
needing
some
kind
of
resolution
rules
that
say
if
you
want
to
collapse
all
these
things
together
in
some
way
like
on
a
back
end.
D
How
should
things
take
priority
right
if
you've
got
effectively
a
db
client
span
for
elasticsearch
that
then
wraps
an
http
client
span?
How
do
you
kind
of
smush
those
fields
together
so
that
you
can
one
example
would
be
representing?
What
is
the
remote
service
name
right?
So
if
you
don't
have
tracing
on
the
other
side
or
the
thing
on
the
other
side
is
a
remote
like
a
a
service
that
you
don't
own.
Facebook
api
would
be
an
example.
How
do
you
resolve
these
things
so
that
you
get
a
consistent,
remote
service
name.
A
E
I
don't
know
I
I
think
what
andrew's
saying
is
probably
the
right
move
forward,
though,
which
is
just
like
make
the
spec
like
allow
for
yeah.
I
guess,
if
we're
down,
to
encourage
people
to
say
like
if
possible,
to
collapse,
please
do
so
like
we
need
to
have
logic
around
that.
E
I
don't
know,
I
don't
have
a
good
answer
I'll,
be
interested
to
see
what
the
maintainers
come
up
with
and
we'll
you
know
handle
it.
I
guess.
D
Cool
okay,
yeah.
You
know,
we've
tried
pretty
hard
to
only
create
a
single
client
span
and
to
pass
down
additional
tags
that
are
required
that
you
know
we
want
to
decorate
that
span
with
and
on
the
server
side,
we've
tried
to
create
a
single
rack
span
that
is
then
augmented
with
information
from
rails
as
it
comes
in,
but.
B
D
The
ability
to
simply
propagate
the
headers
as
they
come
in
and
you
effectively
end
up
with
a
transparent
service.
So
I
believe
the
way
things
would
work
right
now.
You'd
end
up
with
the
default
configuration
if
you're
just
using
api
you're
going
to
end
up
with
a
non-recorded
span
and
then
you're
going
to
inject
headers
potentially
into
the
outgoing
requests
that
will
be,
will
have
a
different
trace
id
and
span
id
so
you're
effectively
breaking
the
trace.
If
you
have
a
service
that
acts
as
an
intermediary
but
doesn't
actually
do
any
tracing.
C
You
can
imagine
situations
where
you're
using
like
like
envoy
or
using
what's
the
other
one,
linker
d
yeah
whatever,
and
you
don't
want
you
really
don't
care
those
things,
don't
add
any
value
or
in
our
case,
like
we
use
aj
proxy
in
between
and
it's
like,
we
don't.
We
may
not
care
about
those
in
every
instance
for
every
set
of
applications
and
how
they
speak
with
each
other.
C
We're
really
interested
in
the
application
code
right
and
and
treating
those
hops
the
same
way
as
if
as
if
it
was
just
a
network
happen
like
we're,
not
tracking
network
switches
in
our
traces
right.
B
F
B
F
Like
is
it
overhead
in
the
developer's
brain
and
having
to
write
the
the
deserialization
and
serialization
of
the
headers,
or
is
it
the
overhead
of
asking
compute
to
do
this,
which
you
would
have
to
do
in
some
sort
of
spec
pass-through
propagator
anyway,
like.
C
I
wonder
if
maybe
what
we
need
is
more
clarity
on
here,
and
perhaps
we
should
ask
them
for
use
cases
on
which,
because
I
guess
I
I
was
also
speculating
about
what
those
use
cases
were
and
the
way
that
rob
phrased
it.
I
was
just
like
yeah
that
sounds
like
not
a
necessary
to
do.
Just
don't
touch
them.
If
you
don't
want
them
right.
D
Yeah.
Okay,
sorry,
I
wasn't
clear
on
this,
so
yeah,
okay,
I
guess
the
way
the
propagators
would
work.
If
you
weren't
doing
anything,
you
would
extract
the
contacts
from
the
y
you'd
have
to
do
all
the
parsing
etc.
Stick
it
in
the
local
context
and
then
for
outbound
requests.
You're
just
going
to
inject
that
same
context,.
A
A
E
A
I'm
just
I'm
curious
again.
This
is
just
speculation
at
this
point,
but
like
I'm
wondering
how
often
use
cases
are
going
to
come
up
where
people
aren't
necessarily
totally
interested
in
tracing
itself,
but
more
of
using
as
a
means
to
just
pass
information
along
from
one
service
to
another
like
outside
of
the
observability
context
like
this
application's
gonna.
Do
something
it's
really
convenient
for
me
to
just
like
shuffle
some
value
into
there,
and
I
don't
want
anyone
to
do.
A
D
Arguably,
you
could
abuse
baggage
for
that.
F
A
Probably
already
doing
it,
so
I
just
I
wonder
how
much
traction
that's
going
to
get
or
if
there's
going
to
be
any
push
for
that
and
how?
How
like
what
the
reaction
should
be
to
that,
because,
obviously
it's
not
the
the
spirit
of,
I
don't
think
it's
in
the
spirit
of
what
all
of
this
is
for.
But
like
do
you
want
to
deny
someone
from
just
using
it?
I
don't
know
just
an
open-ended
thought.
D
Okay
cool:
I
will.
A
No,
I
just
I
just
thought
it
was
it's
just
it's
what
it's?
What
I
thought
of
when
I
looked
at
this
and
like
we
were
talking
about
what
the
motivations
were
for
and
I
just
like
I
was
like.
Why
would
somebody
want
to
do
this?
Why
would
they
just
want
to
like
kind
of
transparently
hop
through
a
service
but
keep
everything
going
and
it's
like?
Well,
maybe
they
want
to
use
baggage
to
communicate
like
between
services
like
I've
done
some
hacky
stuff
in
my
life.
F
C
C
Like
hey,
we've
got
these
we're
sending
you
headers
you
mind,
sending
us
back
those
headers
so
that
we
can
see
the
hop
that
hits
your
system
and
then
it
goes
back
to
hours,
because
for
whatever
reason
it's
designed
a
way
or
that
they
call
us
back
and
we
receive,
and
then
we
call
them
back
so
it's
kind
of
like
when
does
the
trace
end,
but
that's
a
whole
other
ball
of
wax.
D
Cool
is
my
video
still,
oh
sorry,
my
screenshot
still
working.
Can
you
see
open,
telemetry,
ruby?
I
see
it.
Okay,
wonderful,
okay,
so
I
guess
we're
done
with
the
spec
related
things,
or
at
least
the
things
that
matt
shared
with
us.
D
What
do
we?
What
else
do
we
want
to
talk
about?
I
know
somebody
was
talking
about
joining,
but
I
guess
they're
not
here
to
discuss
this
issue,
which
was
consistent,
http,
request
attributes.
D
E
E
Do
you
think
it's
worth
ships,
you
know
if
I
went
and
just
shipped
like
a
skeleton
type,
you
know
the
hopeless
thing,
yeah
skeleton
helpers
thing
then
he
could
just
rebase
off
master
and
and
whatever
add
it
there
yeah.
I
think
that
would
be.
D
Fine
yeah,
the
the
main
thing
that
I
brought
up
was
instrumentation
options.
D
I
think
it's
worth
doing
in
this
pr.
You
know
he's
going
and
adding
the
option
to
all
the
instrumentation
anyway
figuring
out
how
to
factor
that
out
nicely,
and
then
you
know
include
that
module
in
all
the
places
seems
reasonable
to
do.
D
E
Yeah,
I
think
that
makes
sense,
and
you
just
include
that
in
the
I
don't
know,
whatever
the
the
patcher
I
forget,
what
file
is.
D
Yeah,
it's
the
actual
instrumentation
gems.
So
let
me
I'm
sorry
I'm
terrible
at
navigating
here.
So
if
we
look
at
faraday
instrumentation,
we
add
this
option
hide
query
params.
Instead,
you
just
have
an
include
that
would
add
that
option,
for
you
make
sense.
E
D
E
D
Okay
is
there
anything
folks
specifically
want
to
talk
about
here
if
you've
got
an
open
pr
that
you
want
to
get
more
context
on
or.
E
B
We
ever
decide
what
we
would
do,
what
what
to
do
about
the
elasticsearch
instrumentation.
I
know
we
had
a
discussion
a
couple
of
weeks
ago
about
how
it
felt
like
we
could
just
inject
the
faraday
instrumentation
into
that
into
the
client
and
then
maybe
instrumenting
the
elasticsearch
client
api
would
be
more
useful
rather
than
the
http
operations,
but
I
I
feel,
like
it's
stalled.
Yeah
rob
posted
an
update
to
that.
Oh.
A
Yeah
so
like
the
tldr
there's
like,
let's
just
leave
the
name
and
then
I
I
went
through
elasticsearch
and
like
actually
took
the
time
to
look
at
how
the
gem
was
structured
like
more
closely
so
and
some
previous
comments
said:
there's
like
this
transport
api.
A
A
So
like
the
repo
is
like
nice
and
organized
the
issue
would
be
is,
if
you
wanted
to
add,
like
a
singular
instrumentation
point
to
the
api,
I'm
not
sure
what
that
would
look
like
sort
of
something,
probably
pretty
unwieldy,
because
there's
no
common
inheritance
or
shared
kind
of
choke,
instrumentation
point
to
like
get
more
information.
So
you
have
to
add
a
span
to
like
hundreds
of
methods
or
whatever,
which
just
seems
kind
of
weak.
I
don't
know.
A
So
then,
that
leads
us
to
kind
of
what
the
state
of
pr
is
right
now,
where
it's
instrumenting
elastic,
search
transport,
which,
if
we
leave
it
as
is
it
it'll,
look
like
it's
just
a
thin,
like
your
spans,
will
just
be
like
an
http
spam.
Basically
wrapping
your
faraday
http
spam,
so
you
look
like
you'll
have
duplicates
banned
there
and
there
the
elasticsearch
one
isn't
really
enriching
the
choice
with
anything.
A
So
what
I
encouraged
the
the
author
to
do
is
like
look
at
like
something
like
koala,
which
is
the
facebook
gem
that
is
getting
a
lot
of
references
today,
but
basically
just
do
the
http
context,
propagation
thing
to
pass
down
to
faraday,
and
then
I
left
like
an
open-ended
question
whether
or
not
we
should
depend
on
faraday
instrumentation
as
part
of
its
install
process
and
thinking
about
it
more.
A
I
don't
necessarily
want
to
make
installing
it
a
responsibility
of
this
gem.
I
think
that
like
if
someone
doesn't
want
to
do
any
configuration
any
setup
like
francis
kind
of
suggests
this
like
they
can
use
instrumentation
and
look
at
everything
right,
it'll,
auto,
detect.
What's
there
and
it'll
just
work,
but
if
they
don't
want
to
do
it,
I
think
it's
reasonable
to
say
if
you're
using
the
elasticsearch
instrumentation,
you
should
add
the
faraday
instrumentation
and
the
two
work
nicely
together.
A
I
just
I
think
right
now
it
would
be
fine,
but
I
don't
like
the
future
possibility
of
a
bunch
of
different
gems
trying
to
install
each
other
and
like
if
we
have
elasticsearch
trying
to
install
faraday
what
if
we
have
another
gem,
that's
trying
to
install
faraday
and
like
watch
koala,
try
to
install
fair
day
like
it
just
it
seems
like
it
could
get
kind
of
wild
from
lack
of
better
language
on
my
part
so
like
to
sum
that
up
is
like.
A
B
Yeah,
I
think
my
thought
about
it
had
been
similar
to
how
you
might
instrument
active
record
at
a
higher
level
than
sql
you
might
have
there.
Might
there
is
some
value
there,
for
example,
but
yeah?
If
it's,
if
it's
as
messy
as
you
say,
then
that's
just
going
to
be
a
nightmare
and
not
worth
our
time,
because
we
won't
be
able
to
do
it
very
well
and
it'll
end
up
being
not
great
quality.
If
we
don't
do
a
good
job
of
it
and
if
it's
really
dozens.
B
Methods,
I
would
say
that
none
wait
and
it
doesn't
seem
like
it
provides
much
value.
Then
yeah,
I
would
say
we
shouldn't,
do
it
either
yeah.
I
guess
the
only
thing
that
has
come
into
mind
about
the
faraday
thing
is:
if
somebody
installs
to
get
this
nice
sort
of
synergy
to
use,
one
of
my
least
favorite
words
you
need
to
add
and
install
and
set
up
faraday
you'll
end
up
instrumenting
a
lot
of
other
things.
F
I
say
that
you're
using
the
instrumentation
gem-
and
I
don't
see
the
faraday
instrumentation
down-
know
that
there's
some
synergies
available.
If
you
choose
to
see
this
documentation,
so
it's
not
going
to
do
any
automatic
stuff,
but
it
can
detect
the
absence
of
the
faraday
instrumentation
and
notify
a
human
that
they
have
more
options
and
where
to
learn
more,
is
that.
A
Yeah
yeah,
that's
that's
an
interesting
idea.
I've
never
really
looked
at
any
of
the
like
install
hook
site,
the
only
one
I
think
of
is
like
hdtv
party
and
the
much
controversial
message
there
that
I'm
in
the
camp
over
that
it's
fun.
So,
let's
not
say
anything
otherwise.
The
other
thing
that
I
was
thinking
too
for
this
is
like
in
the
world
where
someone,
for
whatever
reason,
absolutely
does
not
want
faraday
instrumentation
for
just
a
general,
but
they
want
elastic
search
instrumentation.
A
So
then
you
would
get
you
would
get
the
same
level
of
instrumentation
that
you
get
with
faraday
without
faraday
instrumentation,
and
I
don't
know
what
the
use
cases
that
looks
like
I
don't
know
if
we
should
start
with
that
being
how
it's
set
up,
but
it
seems
totally
reasonable
to
me
because
it's
it
seems
like
it's
something
that
could
just
be
a
configuration
option
in
that
regard.
C
Part
of
me
feels
like
this
is
a
different
view
of
this
of
the
client
mankind
conversation
where
it's
like.
C
What
granularity
do
we
want
and
how
unique
something
should
be
so,
whether
or
not
something
should
be
a
span
for
a
lower
level
library,
the
lower
you
get
into
the
stack
and
how
to
group
attributes
like
one
implementation
might
be,
I'm
only
generating
one
span
and
then
amending
attributes
that
are
namespaced
and
assembling
them
down
the
line
until
I
get
down
to
say
net
acv
or
something
like
that
where
it's
like,
we
have
a,
and
we
see
one
span
with
many
attributes
that
are
from
different
instrumentation
versus
having
multiple
spans,
not
that
that's
a
solution
that
I'm
suggesting
here,
but
when
we
start
looking
at
like
the
do,
we
extract
an
http
utility
library
that
has
all
of
the
semantic
conventions
built
into
it.
C
C
That
says
this
is
the
thing
that
generates
the
lead
span
or
whatever
all
different
strategies
to
try
to
address
this
problem,
but
the
more
the
downside
of
this
is
as
more
configuration
and
that's
what
we're
trying
to
get
away
from
right,
yeah
and
like
what
do
we
want
to
be
the
default
use
case?
What's
the
most
intelligible
thing
for
me
as
an
engineer.
B
I
think
yeah,
I
honestly,
I
don't
know
I
really
don't.
I
also
worry
that,
like
we've,
we
have
partially
through
me
bringing
it
up
to
start
with
gone
down.
You
know
this
road
of
like
trying
to
hyper
optimize
this
case
when
like
in
reality.
This
is
gonna
happen
for
a
lot
of
other
things
that
have
faraday
dependencies
under
the
hood.
There's
going
to
be
a
lot
of
duplication
just
because
faraday
underpins
so
much
of
anything,
that's
http
related
these
days
yeah.
I
guess
I
don't
really
know
what
to.
F
Do
my
experiments
with
open
telemetry,
ruby
and
using
faraday
and
all
of
its
its
abstraction
of
the
other
http
libraries
is.
If
you
go
down
the
open,
instrumentation,
all
you're
gonna,
get
it
all
and
at
a
point
where
you
don't
want
all
instrumentation
you're
in
the
world
of
a
curated
list
of
which
instrumentations
you
want
to
turn
on
and
yeah.
D
Yeah
and
practically
speaking,
that's
what
we've
done
at
shopify
right,
we're
not
using
instrumentation.
All
we've
got
our
own
curated
list
of
things
that
people
like
are
either
approved
for
use
of
shopify
or
they're,
typically
used
to
shopify,
and
we've
we've
like
encoded.
That
list
into
our
wrapper
jam
for
open,
telemetry,
ruby,
so
and
and
and
you
could.
F
Without
without
a
rapper
gem
you
could
a
user
of
these
instrumentations
could
say
I
want.
I
want
the
gem
instrumentation
all,
but
when
I
go
to
configure
open
geometry,
ruby,
here's
the.
A
C
Don't
have
to
call
it
using
this
fan
yeah.
This
granularity
granularity's,
like
reminded
me
of
how
like
more
sophisticated
logging
libraries,
will
do
things
like.
I
want
to
be
able
to
down
to
this
specific
name
space.
This
package,
I
want
to
a
debug
log
level
versus
the
rest
of
these,
only
go
to
error
or
worn,
and
it's
kind
of
like
we
don't
have
a
model
for
that
other
than.
F
F
Because,
like
you
said,
like
you
said,
it's
like
the
client
server
span
issue
and
how
granular
you
get
there.
I
because
we
don't
have
conventions
around
names
for
these
different
layers
of
abstraction.
I
think
it's
the.
If
you
do
use
all
bang
you're
going
to
get
them
all
and
if
you
don't
want
them
you're
in
a
world
of
like
naming
the
ones
that
you
want.
Unless
we
we
don't
have
an
exclude.
Do
we
like.
A
F
Keep
faraday
but
like
turn
off
all
the
instrumentation
on
the
other
http
library.
Yes,
if
you
don't,
if
you
don't
want
the,
if
you
don't
want
instrumentation
from
the
libraries
faraday
is
using
you
just
just
tell
me
when
faraday
gets
used,
because
faraday's
used
everywhere
whatever
or
did
I
misunderstand
the
scenario.
D
The
scenario
would
be:
if
you
had
one
particular
instrumentation
gem
that
you
wanted
to
disable,
then
you
could
just
say
enable
false
for
that
one
yeah
well.
F
I'm
picturing,
if,
if,
if
I
know
faraday
is
used
everywhere,
just
like
all
my
http
requests
are
going
through.
Faraday
only
show
me
spans
from
faraday
and
don't
show
me
the
underlying
hp
library
fair
days
using
yeah.
D
D
List
code,
but
yeah,
hopefully
you're
not
using
too
many
http
libraries.
F
F
A
list
of
all
the
http
clients
that
your
code's
using
this
is
useful
information
and
then,
when
you
decide
that
it's
not
useful
information,
you
can
start
turning
them
off
right.
But
that's
like
that's
a
block
list.
Yep
you
should
you
have
to
maintain
block
lists,
yeah
or
don't
use
all
I
feel
like
that's,
okay,
yeah.
I
think.
D
C
D
D
Is
there
anything
else
people
want
to
discuss
in
terms
of
pull
requests
right
now
I
did
open
this
monotonic
clock
thing.
This
is
a
follow-up
to
a
change
that
went
out
shortly
before
the
rc.
Well,
I
guess
we
took
so
long
with
the
rc
that
it
wasn't
shortly
before,
but
about
a
month
ago
we
made
the
change
to
have
exportable
timestamps
all
be
integer
nanoseconds,
since
epoch.
D
Trying
to
use
monotonic
clocks
internally
inside
spans,
so
that
if
you
have
a
start
time
stamp
that
is
generated
by
the
span,
it
will
take
if
it.
If
it's
got
a
parent
span,
that
has
a
trustworthy
monotonic
time
stamp
and
wall
clock
time
stamp
real
time
time
stamp.
Then
it
will
use
both
of
those
as
the
base
to
compute
its
base.
D
Otherwise
it
will
grab
the
wall,
clock
time
and
the
monotonic
time
and
then
subsequent
time
stamps
within
that
span.
So
the
end
time
stamp
any
event.
Time
stamps
that
are
not
explicitly
provided
will
use
the
monotonic
offset
to
actually
compute
the
time.
So
this
means
that
you
get
like
by
default.
If
you're
not
explicitly
passing
a
start
time
end
time
stamp
or
event
time
stamp,
you
will
get
durations
that
are
sensible
right.
So
your
end
time
is
going
to
be.
You
know
so
many
nanoseconds.
D
Since
your
start
time,
instead
of
whatever
your
wall
clock
time
happens
to
say
at
the
end
time,
including
any
time
corrections
that
have
been
made
in
the
meantime.
Sorry,
that's
too
many
times.
E
I
think
the
approach
works.
I
actually
didn't
think
about
events,
so
I
have
to
review
that
part,
even
though
I
already
approved
this
but
yeah.
It's
so
there's
some
weird
edge,
not
edge
cases,
but
the
you
know
the
like
matrix
of
like
of
of
outcomes
or
whatever
is
surprisingly
confusing,
but
yeah.
D
I
did
call
out
here
there's
one
edge
case
that
I
haven't
dealt
with,
which
is,
if
the
start
time
stamp
is
explicitly
provided
then
subsequent
time
stamps
in
the
same
span
so
event
times
and
the
end
time,
not
using
monotonic
clocks,
because
somebody
gave
you
an
explicit
timestamp
and
you
know,
maybe
it
represents
a
completely
different
time,
but
it's
possible
that
we
could
actually
do
that
as
well.
We
would
just
need
to
sorry.
D
Need
to
just
determine
the
difference
between
that.
You
need
to
yeah,
you
need
to
end
up
creating
a
kind
of
a
different
time,
stamp
different
start
time
stamp
to
use
as
the
base
for
subsequent
things,
which
means
that
you
need
to
keep
instead
of
right.
Now
we
have
a
start
timestamp,
which
is
the
wall
clock
time
which
may
be
computed
or
maybe
just
taken
from
process
clock
at
time,
and
then
we
have
a
monotonic
start
time
stamp.
D
B
I
think
the
only
thing
that
comes
to
mind
about
that
is
to
bring
up
our
favorite
thing
to
discuss
and
not
implement
is
if
you
are
doing
something
with
like
active
support
notifications,
where
you
might
actually
want
to
be
manually,
setting
those
time,
stamps
or
or
other
sort
of,
if
you're
I
I
can
think
of
cases
where
you
might
want
to
pass
in
the
start
time
stamps
and
not
have
that
be
a
strange,
exceptional
case.
But
there's
I
don't.
B
D
Yeah
there
are
two
that
I
know
of
one
is
for
messaging
systems,
so
kafka
as
an
example.
If
you
want
to
create
there
are
scenarios
where
you
want
to
create
a
receive
span
that
has
a
reference
to
the
send
span,
but
you
haven't
actually
like
you
can
only
pass
in
links
when
you're
starting
the
span,
which
means
you
can't
actually
start
the
span
until
you've
received
the
message.
D
So
the
only
thing
you
can
do
there
is
keep
track
of
the
start.
Time
of
the
receive
call
then
do
the
receive
call.
Now
you've
got
the
message
in
your
hand,
you
create
a
span
that
uses
start
time
that
you
had
previously
kept
around,
and
then
you
probably
immediately
finish
the
span.
So
that's
one
example.
D
Another
example
is
in
the
I
think
it's
in
the
rack
code
there's
a
path
where,
if
the
load
balancer
injected
in
like
a
header
representing
queuing
time,
you
can
use
that
to
create
a
a
span
that
represents
the
load
balancer
yeah.
So
I
think
we
refer
to
that
as
a
front
end
span.
So
those
are
two
examples
where
you
you
create
the
span
later
on.
Using
a
time
stamp
that
you
grabbed
from
somewhere,
so
sorry
rob.
You
were
trying
to
comment.
F
Earlier,
I
think
it's
mostly
me
trying
to
make
clarifying
statements
to
see
if
I
understand
it,
but
I
don't
think
I
understand
it
well
enough
to
make
those
statements
so
I'll
just
keep
listening
and
read
code
and.
E
Basically,
if
we
can,
if,
if
circumstances
per
minute,
try
to
use
monotonic
time
but
there's
a
variety
of
circumstances
where
we
can't
make
those
assumptions,
but
we
may
need
to
store
time,
you
know
it's
like
you
may
need
to
store
the
time
stamps
until
you
know
for
sure.
So
I'm
not
explaining
that
well!
Well,
it.
F
F
Conceivably
have
three
different
start
times
for
for
a
particular
span.
It's
you've
been
given
one
and
then
that's
the
most
like.
I
don't
know
what
to
do.
But
if
you
haven't
been
given
one
we
find
monotonic
start
and
then
whatever
processes
and
then
when
end
is
called
that's
we
find
them
basically
the
monotonic
end
and
do
the
math
figure
out
the
duration
and
and
you're
good
to
go.
Yeah.
D
It's
basically
duration
is
not
explicitly
represented
in
open
telemetry.
It's
implicitly
represented
as
a
start
time
and
an
end
time,
so
we
want,
like
duration,
tends
to
actually
be
an
important
thing
that
you
want
for
analysis.
So
you
want
your
end
time
to
be
some
offset
from
the
start
time.
D
But
if
you
have
you
know,
clocks,
changing
in
between
the
start
and
end
times,
then
you're
better
off
using
a
monotonic
time
to
compute
the
end
time
as
the
offset
from
the
start
time,
but
yeah
there's
three
scenarios
that
are
interesting.
One
is,
I
was
explicitly
given
a
start
time
stamp,
in
which
case
all
bets
are
off
for
that
time
stamp.
D
But
what
about
other
time
stamps
that
are
created
like
event,
time
stamps
and
end
time
stamps?
So
that's!
Oh,
yes,
okay!
That's
the
thing
I'm
trying
to
figure
out
here!
The
second
scenario
is,
you
know,
let's
say
I'm
a
local
root
span:
either
I'm
an
actual
root
span
or
my
parent
was
pulled
off
the
wire.
D
In
that
case,
I
have
an
implicit
start
time,
so
I
grab
the
real
time
and
the
monotonic
time,
and
the
real
time
is
my
is
used
as
my
start
time
stamp,
but
the
monotonic
time
is
used
as
a
base
for
computing
other
timestamps,
it's
like
the
internal
timer,
that's
youtube
figure
out
whatever
duration
and
add
it
to
the
one
that
was
given
yep
and
then
the
third
case
is
I'm
an
internal
span.
I
have
a
local
parent,
it
had
a
real
time
and
a
monotonic
start
time.
D
Yeah,
so
generally
speaking
for
internal
spans,
or
you
know,
you're
you're
operating
within
a
single
process,
so
you
want
your
durations
to
make
sense.
You
want
your
offsets
to
make
sense
so
that
your
start
times
you
know
internal
span.
D
D
E
D
Context,
you
don't
know
what
its
start
time
stamp
was,
so
you
create
a
start
time
stamp
of
your
own
from
your
wall,
clock,
okay,
but
you
also
record
the
monotonic
time
stamp
so
that
you
can
use
that
internally
to
compute
the
other
timestamps.
D
What
happens
then,
on
the
back
end,
is
that,
depending
on
the
backend,
things
like
jaeger
will
try
to
shift
timestamps.
So
if
you
seem
to
have
a
a
server
span
that
started
before
the
client
span
parent,
it
will
try
to
adjust
the
start
time
of
everything
nested,
underneath
that
to
sit
to
make
the
nesting
look
appropriate.
D
D
Okay,
yeah
but,
as
I
say,
there's
this
one
corner
case
here,
where
the
time
the
start
time
stamp
is
explicitly
provided,
but
subsequent
timestamps
and
not
explicitly
provided
what
should
we
do
in
that
case
and
right
now,
I'm
just
saying
well
we're
just
not
going
to
trust
it,
in
which
case
everything
becomes
war
clock
after
that,
but
maybe
we
should
do
something
different,
so
that
was
the
open
question
yeah.
D
If
people
want
to
take
a
look
at
that,
that
would
be
really
helpful.
Also,
I
have
that
fun
little
question
about
how
do
we
test
this.
F
That
one
seems
like
a
plucking
a
lot
of
the
decision-making
out
into
methods,
and
then
we
can
make
assertions
that,
given
these
start
scenarios,
we
we
go
down
that
path
and
not
try
to
control
time.
I'm.
E
D
E
D
Time
cop
handle,
I
know,
it'll
handle,
there's
a
time
dot
now
and
things
like
that.
D
So
I've
introduced
these
two
wrappers
real
time
now
and
monotonic
now
as
private
methods
inside
span.
So
arguably
we
can
just
mock
those
yeah
to
do
that.
F
That's
right,
I
would
recommend
we'd
the
matrix
of
scenarios.
I've,
given
these
inputs
we're
going
to
figure
out
time
this
way
and
then
the
don't.
It's
a
little
bit
more
integration,
a
test
rather
than
unit
testing
that
we're
doing
time,
math
correctly,
just
yeah,
because
time
yeah.
What's
that
date,
math
yeah,
love
it
sorry
it's
otherwise!
It's
I
don't
know
how
valuable
those
tests
would
be
if
yeah
and
they're
going
to
be.
D
E
C
Like,
oh,
ruby,
ruby
handles
calendars,
it
was
the
year
2000,
wasn't
it.
That
was.
E
D
B
D
A
What
it's
worth
it
is
ready.
I
believe
it
is
ready.
I
actually
looked
at
some
of
the
active
job
stuff
and
brought
it
over
andrew's
gently
commenting.
Maybe
you
should
look
at
this
and
hopefully
I
didn't,
and
then
I
did
I
was
like
oh
wow.
I
should
do
that,
so
I
have
done
that
now,
so
I
think
it's
in
a
good
place
for
people
to
look
at
if
they
would
like
see.
I
was
kind
of
awkward
because
of
the
recent
changes
it
was.
A
I
fought
with
it
a
lot
because
one
of
the
best
few
versions
was
trying
to
pull
it
on
an
old
redis
and
it
was
breaking
in
ci,
but
it
was
working
locally
for
some
reason
for
me,
so
I
had
to
do
some
weird
stuff
appraisals
there
and
then
I
had
to
add
the
omit
ci
thing
for
mac
and
windows
because
it
uses
underlying
anyways.
That's
maybe
like
the
only
oddity
about
this
once
everyone's
happy
with
this
one.
My
intention
is
to
go
and
update
sidekick
to
the
consistent
with
this.
So
it'd
be
nice.
B
There
likewise,
regarding
unification,
if
once
we've
reached
consensus
on
the
rescue
instrumentation
with
the
option,
names
and
stuff
I'll,
just
make
sure
that
the
active
job
stuff
matches
it.
That
is
similarly
also
ready
for
anyone
to
look
at
assume
the
option.
Names
might
change,
I
guess,
but
the
mechanism
should
be
solid.
I
think
at
this
point,
cool.
D
I'll
try
to
take
a
look
at
that
this
week.
We've
got
one
minute
left.
Somebody
from
the
technical
committee
is
reviewing
the
api
and
sdk
rc1
today
or
tomorrow,
so
yeah.
Hopefully
we
end
up
with
a
bunch
of
issues.
I
guess
hopefully
it's
perfect,
but
you
know
second
best
is
ending
up
with
a
bunch
of
issues
there
that
are
compliance
related
that
we
can
then
dive
into.
C
I
was
gonna,
add
just
one
thing
more
of
a
process
name
with
folks
coming
in
asking
for
help
or
when
they
get
stuck
on
stuff,
if
they're
not
actually
reporting
an
issue
or
providing
any
code
examples
or
anything,
let's
move
them
out
of
issues
and
put
them
into
discussions
and
there'll,
be
more
of
like
a
fact.
Look
up
thing
for
folks
who
are
having
trouble
because
just
open
an
issue
and
say
this
doesn't
work.
That's
not
helpful.
I
think
to
anybody
here
and
half
the
time.
It's
like
some
misunderstanding.
C
So
I'm
gonna
defer.
You
know
I'm
going
to
default
to
just
like
transferring
them
to
discussions
if,
as
they
come
in,
as
I
see
them,
yeah
that's
cool.
I
hope.
That's.
Okay,.
F
E
I'm
just
kidding,
we
have
a
template
in
our
open
issue
for
like
create
a
bug.
Report
type
thing.
I've
seen
I
can.
Okay,
maybe
that's
a
chore
I
can
take
care
of
aws
is
a
really
good
repo,
a
really
good
template
that
is
like
hey.
Is
there
a
reproduction
hey?
Is
there
a
code
snippet
like
did
you
have.