►
From YouTube: 2020-10-27 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).
C
Here,
where
are
you
at
robert
I'm
in
winnipeg,
so
have
you
ever
heard
of
winnipeg?
I
have
heard
of
winnebago.
C
A
B
D
Kind
of
amusing-
I
think
one
of
our
db
admins
recently
moved
from
winnipeg
to
nova
scotia.
B
B
B
A
B
I
think
I
ended
up
in
a
place
which
is
okay,
I'm
really
happy
to
take
pointers
on
how
to
do
it
better,
but
it
it's
effectively
just
like
the
application
config
and
because
it's
controller
stuff,
I'm
just
requiring
the
action
controller
rail
tie,
which
does
all
the
heavy
lifting.
And
then
I've
got
a
couple
of
mock
controllers.
A
A
B
Yeah,
I
ended
up
just
like
looking
at
how
some
of
the
rails
tests
themselves
were
set
up
and
that
helped
and
I
ended
up
with
probably,
but
I
just
dropped
a
link
of
the
contextually
relevant
bit
there.
B
Am
I
getting
like
the
full
rails
behavior,
with
this
simulation
and
like
I
have
been
testing
alongside
like
an
actual
rails,
app
that
I
use
for
playing
with
this
stuff
so,
like
I
just
have
it
pointing
at
my
little
instrumentation
locally
on
my
machine
and
like
I
just
have
a
couple
simple
controllers
set
up
and
I'll
just
like
spam,
some
requests
and
have
it
fire
off
to
yeager
and
see
what
they
look
like.
So
I've
been
doing
that
alongside
these
tests.
A
Yeah
I
mean,
if
you're
looking
at
rails
itself,
to
see
how
it
sets
things
up.
This
is
probably
a
really
good
example.
My
guess
is
that
there
are
probably
some
examples
in
dd
trace
as
well.
A
C
B
B
E
B
E
B
I
just
want
to
kind
of
leave
it
open-ended
and
I
don't
necessarily
even
want
to
add
all
the
config
variables
yet
because
it's
just
like,
I
don't
want
to
guess
at
what
configuration
makes
sense.
But
I've
tried
to
like
really
be
mindful
of
how
I
structure
it
so
like
just
maybe
someone
doesn't
want
the
rail
tie
and
wants
to
do
it
themselves
cool,
but
they
still
want
to.
Like.
Maybe
do
some
other
stuff.
I
don't
know.
B
Right
and
then
the
config
is
also
in
available
in
the
rail
tie,
which
I'm
not
sure
if
that's
going
to
be
confusing,
but
you
could
potentially
like
pass
in
some
configuration
into
the
rail
tag
because
it's
like
that's
where
we
add
the
middleware
and
maybe
our
middleware
will
be
configurable
like
I.
Don't
I'm
not
sure
how
far
the
rabbit
hole
might
get
with
all
this,
because
rails
is
obviously
a
pretty
complex
framework.
So
I'm
just
trying
to
leave
it
really
really
kind
of
open
to
extend.
A
Yeah,
no,
I
think,
that's
always
a
good,
a
good
approach.
I
think
it's
really
hard
to
know
what
people
want
to
configure.
You
know
as
you're
going
through
things.
You
can
always
imagine
a
thing
where
someone
would
want
a
configuration
for
things.
So
you
know
some
things.
A
Some
things
you
have
a
really
good
idea
about.
Some
things
are
unknown,
but
just
structuring
it
so
that
you
can
always
add
it
in,
I
think,
is
a
good
idea
and
not
not
worrying
too
much
about
what
needs
to
be
configured
right
off.
The
bat,
I
think,
is
also
aim.
A
B
E
A
pretty
good
way,
I
think
I'm
going
to
do
this.
If
you
want,
you
have
a
lot
of
experience.
B
E
A
Cool:
it's
it's!
It's
exciting
to
see
this
in
progress
and
see
something
up
there.
So
I'll
try
to
have
a
look
through
it
sometime
this
week
or
in
the
next
day
or.
A
A
A
Yeah
so
apparently
the
ga
spec
burn
down
looks
like
this.
It
seems
like
almost
everything
with
trace
is
done.
There
are
like
a
couple
of
things
so.
A
The
rest,
the
stuff
that
is
kind
of
in
the
required,
allow
for
ga
that
isn't
done
as
I
just
like
scan
through
it.
It
looks
like
it's
metrics
related,
so
things
are
looking
pretty
good
on
that
front.
A
So
one
thing
that
people
were
talking
about
at
the
maintainers
meeting
and
also
this
meeting
since
a
lot
of
cigs
are
kind
of
getting
close
to
this
point
where
they're
ready
to
ga
is
asking
you
know,
folks
who
participate
in
various
language
sites
to
try
out
other
languages,
implementations
and
provide
feedback.
A
So
they're
kind
of
like
asking
asking
two
things:
are
there
any
people
who
are
willing
to
try
out
somebody
else's
sdk
and
are
there
any
languages
looking
for
people
to
test
drive
their
stuff?
So
we're
not
on
this
list?
We
can
add
ourselves
if
we
want
people
to
start
looking
at
ruby.
A
I
didn't
ask
right
away
because
we're
kind
of
like
opening
the
door
for
people
to
come,
give
us
a
bunch
of
feedback.
I
just
wanted
to
kind
of
get
get
the
pulse
of
our
community
to
see
it.
Are
we
ready
for
that,
or
did
we
want
to,
like
kind
of
you
know,
dot
some
eyes
and
cross
empties
before
opening
that
door.
D
I
mean
we
have
a
couple
of
open
things
that
we
can
maybe
talk
about
today,
but
by
and
large
I
think
any
feedback
is
good.
So
if
we
want
people
to
come
and
take
a
look
at
it,
that's
great
from
our
perspective,
if
I'm
not
mistaken,
we're
using
hotel
java
in
production,
we're
using
hotel
go
in
production,
I
don't
think
we're
using
hotel
ruby
in
a
production
app
yet,
but
we
do
have
it
in
an
example
app
internally
that
we
use
for
experimenting
with
different
things
like
different
exporters
and
so
forth.
A
So
yeah
it
sounds
like
you
would
be.
Potentially
you
or
shopify
would
be
a
good
place
to
get
some
feedback
given
kind
of
those
experience
in
three
three
different
experience
using
three
different
sdks.
D
Yeah
yeah,
I
mean
I
yeah,
I
I
think
there's
feedback
that
we
can
offer
for
java
and
go.
I
think
the
go
feedback
is
mostly
well
anyway.
It's
probably
not
for
this
meeting
but
yeah.
D
It's
mostly
that,
like
every
release,
changes
like
the
structure
of
the
api
and
sdk
and
like
you've
always
got
to
battle
import
changes
and
minor
api
changes
with
every
every
small
release
which
tends
to
be
frustrating
and
then
the
the
feedback
for
the
java
one
was
just
I'd,
have
to
go
back
and
look
at
it,
but
there
were.
There
was
some
weirdness
around
configuration
that
didn't
behave
like
everybody
else.
A
Okay,
yeah
I'll
try
to
figure
out
more
like
how
should
people
provide
some
feedback
after
actually,
looking
at
this
and
yeah,
I
think
in
general,
like
the
thing
that's
on
people's
minds,
it's
like
are
the
things
like
pretty.
Are
they
close
enough?
Do
they
work
similarly
enough
that.
D
Yeah
I
mean
java
is
substantially
different
from
the
other
apis.
As
far
as
I
can
tell
or
other
implementations,
just
probably
because
of
language
and
platform
features
in
java.
D
A
So
the
next
thing
was
there's
a
spec
pr
for
attributes,
pluralization
guidelines,
it
seemed
kind
of
small.
I
don't
know
it
seems
reasonable
when
the
attribute
represents
a
single
thing.
It
should
be
singular
when
it
represents
multiple
things,
it
should
be
pluralized
and
the
type
should
be
an
array
on
the
surface.
This
sounds
okay,
but,
like
I
haven't
kind
of
looked
through
what
we
have
or
thought
through
this
enough
to
know
if
it
makes
sense
for
everything.
D
Memcached,
for
example,
where
you
want
to
record
the
keys
that
are
specified
in
a
get
command,
and
there
could
be
one
there
could
be
many
so
and
if
it's
a
single
entity,
are
you
supposed
to
just
call
it
key
and
keys
for
multiple
entities?
But
then
that
makes
analysis
a
little
bit
more
challenging
because
you
need
to
look
at
both
of
those
fields
seems
like
in
general.
In
that
case,
you
probably
want
to
do
keys
and
have
a
an
array
with
possibly
a
single
entry
or
multiple
entries,
so
yeah.
A
D
A
Yeah
yeah:
it's
it's
hard
to
come
up
with
all
the
examples
you
might
want
to
before
approving
something
like
this,
but
on
the
surface
it
seems
not
terrible.
A
A
I
feel
like
these
are
remnants
from
this
there's
an
environment
variable
spec
that
I
kind
of
helped
get
off
the
ground
a
while
ago,
and
I
did
that
just
by
looking
through
a
lot
of
the
sdks
and
seeing
what
environment
variables
existed
and
there
was
definitely
there
was
an
hotel
sampling
priority
and
that
got
kind
of
controversial,
and
I
think
there
was
a
sampler
and
it
was
also
somewhat
controversial.
A
So
I
just
left
them
off,
but
I
think
they
are
trying
to
come
up
with
some
reasonable
ways
to
to
provide
this
information.
A
I
think
the
I
think
the
sampler
is
one
of
the
more
complicated
things
to
try
to
add
an
environment
variable
for
just
because
it's
like
an
it's
an
extension
point.
So
yeah
like
if
you
start
doing.
D
Parent,
based
with,
I
think,
there's
four
different
wrapped
samplers
in
the
parent-based
sampler,
so
that
it
gets
pretty
interesting
to
specify
that
in
an
environment,
variable.
A
D
A
Pr,
I
am
somewhat
interested
just
just
in
the
use
case
like
what's
what's
driving
this
but
yeah,
it
seems
like,
as
things
get
more
and
more
complicated,
you
probably
don't
want
to
set
this
up
by
environment
variable
just
for
your
own.
A
D
A
Yeah,
I
think
the
concept
is
sound.
You
want
to
provide
a
number
between
zero
and
one
that
a
sampler
does
something
off
of
the
name
could
be
bike
shedded
for
as
long
as
anybody
wants
to.
D
D
A
Yeah,
so
I
guess
the
problems
with
it
would
be
just
generally
discovering
this,
knowing
about
it,
understanding
which
samplers
should
care
about
it,
etc.
A
So
the
next
thing,
I
think,
was
maybe
one
of
the
more
interesting
parts
of
the
specs
egg
and
this
is
specify
span
id
creation
with
sampling
and
the
the
idea
was
that
your
trace
may
use
use
like
mixed
sampling
such
that
yeah.
It's
like
you
may
have
some
unsampled
spans
and
then
have
some
samples
spans
and
then
have
some
unsampled
stands
then
have
some
samples
fans
and
in
that
in
that
situation,
if,
if
you're
always
creating
new
span,
ids
like
your
trace
becomes
broken.
A
But
if
you
can
reuse
like
the
the
parent
id.
A
You
can
basically
still
kind
of
keep
the
trace
continuous
in
that
situation.
That
seems
like
the
right
thing
to
do,
probably,
but
that's
kind
of
what
this
pr
is.
D
It's
basically
that
you
always
create
a
span
regardless
of
the
sampling
decision,
but
the
span
may
be
an
api
span
which
is
effectively
not
recording
or
a
an
sdk
span,
which
for
us
means
it's
recording
for
an
api
span.
D
You
would
simply
reuse
the
parent
span
id
as
your
own
spam
id
because
you're
not
going
to
record
it,
but
you
do
want
if,
like
there's
a
child
span
of
your
span,
if
there's
child
spam,
that
is
recording
you
want
it
to
be
connected
back
to
your
parents
rather
than
to
you
right,
because
you're
not
recording.
D
So
this
gets
really
interesting.
If
you
think
about
some
of
the
discussions,
we've
had
around
trace,
verbosity
and
being
able
to
control
the
velocity
of
a
trace
like
basically
remove
some
internal
spans.
Unless
you
explicitly
ask
for
verbose
tracing,
then
this
supports
that
use
case,
because
your
intermediate
trace
points
just
end
up
being
thrown
away,
but
the
parent
span
id
is
propagated
correctly,
so
that
the
kind
of
leaf
spans
from
your
service
are
have
the
correct
parent
set
and
so
on
the
back
end,
your
trace
will
appear
complete
and.
A
Yeah
so
as
this
came
up
like,
I
meant
to
go
start
digging
through
the
code
to
to
see
how
this
actually
works.
I
know
at
one
point
in
time
you
could
provide
a
sampler
like
on
a
per
span
basis.
Is
that
still
true?
D
No,
I
think
our
sampler
is
tied
to
the
tracer
provider.
So
yeah
you
don't
have
a
postspan
thing,
but
your
sampler.
Could
I
mean
you
could
have
a
custom
sampler
that
actually
looked
at
the
span
to
make
a
decision
about
whether
to
keep
it
or
not.
D
So,
potentially
you
could
pass
in
some
extra
information
to
say
hey.
This
is
a
verbose
span.
I
can't
remember:
if
should
sample
takes
some
attributes
or
anything
else?
There
may
be
some
additional
information
that
you
could
pass
in
and
use
in
a
custom
sampler,
but
there
is
the
ability,
with
the
parent-based
sampler,
to
specify,
I
think,
four
different.
D
A
Yeah
that
all
makes
sense,
I
think
the
sampler
per
stand.
I
believe
this
did
exist
at
one
point
in
time.
Maybe
like
a
year
ago,
it
was
there.
There
was.
A
Yeah,
there's
there's
so
many
options
to
start
span,
but
I
think
there
used
to
be
so
many
more
and
one
of
them
was
was
the
sampler.
But
what
you
just
described
makes
sense
and
I
can
see
I
can
see
ways
that
you
could
do
this
with
some
with
some
custom
samplers.
D
Sorry,
just
to
follow
up
on
that
the
there's
actually
five
children
for
a
parent
based,
so
you
can
make
decisions
based
on
whether
the
remote
parent
is
sampled.
The
remote
parent
is
not
sample
the
local
parenting
sample
or
the
local
parent
is
not
sampled,
so
you
can
actually
have
a
whole
bunch
of
different
options.
There.
A
Cool
yeah,
I
mean
the
options
ultimately
end
up
being
endless
just
because
it
is
an
extension
point,
so
you
can,
you
can
do
whatever
you
want
there
and
if
you
want
to
combine
that
even
with
like
a
span
processor,
I
think
so.
The
sky
is
the
limit
on
how
you
want
to
do
this
stuff.
D
Yeah,
I
guess
that's
one
issue
with
this
proposal.
I
think
the
proposal
makes
sense
and
it
works
for
most
use
cases,
but
for
the
cases
where
somebody
has
a
span
processor
that
still
records
even
or
still
emits
a
span,
even
if
it's
set
to
not
record,
then
it
gets
interesting.
A
Yeah-
and
I
think
that's
probably
a
use
case
that
should
be
thought
through.
A
D
Yep
yeah,
we
thought
well,
actually
we
pushed
for
the
trace
proto
to
be
declared
stable
so
that
we
could
comfortably
go
and
use
it
in
production
and,
of
course,
right
after
we
did
that
they
had
to
make
a
breaking
change.
That,
thankfully
didn't
impact
us.
It
only
impacted
the
json
encoding
of
these
things,
but
yeah
stable
is
not
quite
as
stable
as
it
appears.
A
Yeah,
I
think
I
don't
know
from
my
perspective,
this
json
encoding.
All
messages
alpha
is
a
big
problem
for
ga.
Coming
from
like
the
js
sig
from
like
the
browser,
the
only
thing
that
we
can
use
is
json
to
get
spans
out
of
it,
so
to
like
not
have
a
stable
way
to
do.
That
is
not
great.
D
Yeah,
the
other
thing
that
we
discovered,
I
mean,
there's
maturity,
level
of
the
protobuf
encoding
or,
like
this
maturity
level
of
the
encoding
of
things,
but
there's
also
maturity
level
of
the
components
that
interact
with
this
and,
as
we
discovered
this
morning,
the
otol
collector.
D
The
implementation
of
the
receiver
is
reasonably
mature
for
otlp,
but
the
otlp
http
exporter
is
missing
at
least
three
things,
including
like
how
it
handles
back
off
how
it
handles
retries
and
gzip
compression
so
yeah,
it's
like.
Even
if
you
declare
this
to
be
mature
and
stable,
the
implementations
also
need
to
be
stable.
A
But
yeah,
I
think
all
of
us
are
trying
to
use
this
in
some
way,
shape
or
form
and
depend
on
some
level
of
some
accurate
level
of
maturity,
or
at
least
just
understanding
when
things
are
going
to
break
so
that
we
can
use
this
stuff.
D
Oh
yeah,
sorry,
I
forgot
the
other
one
is
that
that
the
url
in
the
spec
is
apparently
tracers
like
it's
v1,
slash,
tracers,
plural,
but
the
implementation
in
the
collector
was
trace.
Singular
so
yeah.
Sorry
that
that's
another
one
that
occurred
to
me
as
I
think
it's
difficult
to
claim
that
these
are
mature
when
you
actually
need
to
use
a
different
endpoint
from
what
the
spec
says
to
make
it
actually
work.
A
Yeah,
I
agree
with
all
this.
A
I
mean
the
bullet
point
was
it
needs
clarity
on
parts
of
the
spec,
but
I
think
there
probably
is
a
larger
discussion
for
for
all
of
us
that
are
actually
trying
to
use
this.
I
do
know
there
was
a
minor
bike
chat
about
trying
to
add
s
to
traces
and
the
the
I
think
the
desire
was
to
have
it
match
metrics,
but
it
turned
out
adding
s
was
going
to
be
a
lot
of
work
for
for
some
people,
but
it
looks
like.
D
I
mean
ironically
yeah
ironically,
the
end
point
in
the
specs
says
traces,
but
the
struct
says
trace
okay,
so
we.
A
So
yeah,
we
didn't
really
get
time
to
talk
about
this
thing.
This
is
one
of
my
pr's
that
has
been
open
for
an
eternity.
It's
basically
just
trying
to
state
like
what
implementations
are
already
doing
for
for
b3
people
keep
picking
apart.
My
wording
eventually
I'll
get
it
right,
but,
like
I
think
the
main
the
main
thing
to
know
about
this
and
our
v3
implementation
and
pretty
much
all
the
b3
implementations
in
open
telemetry
is
that.
A
B3
propagates
propagates,
something
called
span
id,
which
is
the
parent
span
id
or
it
probably
should
be
the
parents
fan
id,
but
then
they
also
propagate
something
called
parent
span
id,
so
they
propagate
two
span,
ids
and
the
reason
it
does.
This
is
so
that
two
sides
of
a
request
can
share
the
same
span
id
if
they
choose
to
so
you
kind
of
need
this
parent
span
id
in
order
to
actually
have
a
parent
to
link
stuff
up
with
in
open
telemetry
right
now.
A
A
So
I
just
wanted
to
write
this
down
somewhere
that
we're
not
propagating
parent
span
id
for
b3
and
we
can't
with
the
current
api
and
if
that's
a
problem,
it's
something
that
needs
to
kind
of
be
addressed
now.
So
that
was
part
of
the
reason
for
opening
this.
A
A
Context
trace
flags
should
be
sampled,
but
you,
you
can
technically
store
the
debug
flag
in
the
context
that
you
have
it
around
for
subsequent
calls
to
inject
scent
if
this
goes
to
a
another
b3
system,
it'll
kind
of
preserve
that
that
flag.
So
that
was
really
what
this
pr
is
about.
D
Does
in
b3
I
guess
it's
not
b3
specifically,
but
in
zipkin,
is
there
a
mechanism
for
exporting
the
the
state
of
this
flag.
D
I
thought
one
of
the
values
it
would
have
is
actually
being
able
to
mock
the
span
as
a
debug
span
for
downstream
processing,
so
that
a
collector,
for
example,
that
is
down
sampling,
would
choose
to
retain
those
spans
and
then
so.
That
means
that
if
you
actually
inject
this
into
a
request
or
set
this
flag
in
a
in
a
kind
of
root
request,
then
it'll
propagate
through
the
system
and
all
the
spans
for
that
trace
will
be
retained.
On
the
back
end,
something
along
those
lines.
A
Yeah
I'll
walk
back
this,
I
don't
think
so
to
I
don't
know
at
all,
but
it
seems
like.
A
It
seems
to
me
like
that
there
is
a
sampling
bit
in
home
b3,
so
there's
likely
to
be
like
a
difference
in
behavior
for
your
zipkin
system
between
just
setting
this
sampling
bit
and
setting
a
debug
flag.
How
that
actually
manifests-
I
don't
know,
but
I
think
the
debug
flag
probably
gets
some
kind
of
like
precedence
like
you
would
really
want
to
collect
that
one.
A
The
other
thing
is,
if
you
were
kind
of
storing
like
probabilities
on
spans
or
something
so
you
can
kind
of
you
know
extrapolate
occurrences
this.
This
debug
would
probably
impact
that
a
little
bit,
so
there
might
be
some
like
special
case
handling
around
a
debug.
For
those
reasons,
I.
D
Suppose
you
might
also
use
its
existence
in
the
context
to
figure
out
whether
you
want
again
like
more
verbose,
tracing.
A
Yeah
that
all
makes
sense,
though
yeah
my
the
yeah.
I
guess
the
main
points,
though,
is
for
for
the
purposes
of
b3
implementations
in
in
hotel.
We
can
preserve
this
flag,
so
we
should.
A
There's
at
least
a
situation
where
there's
no
reasonable
parent
span
id
like
for
like
a
roots
van,
for
example,
but
nobody
has
kind
of
come
in
and
said
that
this
will
totally
irreparably
break
zipkin
systems.
But
that
would
be
good
to
know
if
anybody
does
know
about.
A
A
What
yeah,
so
we
have
10-ish
minutes
left
we're
kind
of
should
probably
start
talking
about
our
repo
a
little
bit.
I
know
we
talked
a
little
bit
about.
D
So
I
have
two
things
I
wanted
to
discuss.
One
is
this
breaking
change
for
spam
context,
particularly
for
link?
I
don't
know
whether
you
have
a
chance
to
look
at
this.
I
guess.
A
I
multitask
during
the
spec
meeting
for
a
second
that
looked
totally
fine
to
me,
especially
since
we're
in
this
world,
where
you
have
you
know
a
dynamic
context
and
span
contexts
like
it.
D
Yeah,
this
all
looks
good
to
me.
Okay,
cool
I'll,
merge
that
after
this
I
also
wanted
once
this
is
in.
I
wanted
to
cut
a
new
release
today.
D
D
Okay,
the
other
thing
I
wanted
to
talk
a
bit
about
was
context
propagation
for
I've,
called
it
layered,
http
clients,
but
I
don't
know
if
you
can
look
at
the
issue
for
this
one.
This
is
443
yeah.
D
So
this,
like
robert
and
I
had
chatted
a
bit
about
this
and
I
decided
to
write
it
down
because
I
think
it's
interesting
in
the
ruby
community.
We
have
a
bunch
of
http
clients.
The
interesting
ones
are
net
http
and
I
don't
know
how
to
pronounce
it
but
tyf
typhus.
D
I
don't
know
anyway
somebody
who's
who
understands
greek
better
than
I
do
probably
knows
what
that
should
be.
So
typhus
is
a
wrapper
around
lib
curl
and
it's
used
for
making
a
bunch
of
requests
concurrently.
D
Then
we
have
kind
of
intermediate
things
like
faraday,
which
lets
you
inject
middleware,
and
then
we
have
high
level.
Clients
like
koala
is
one
example
I
provided
here,
which
is
a
facebook
clients,
facebook,
api
client
and
the
the
interesting
thing
is
that
we
often
want
to
have
a
single
client
span
that
has
information
from
all
these
layers.
We
don't
necessarily
want
to
have
a
bunch
of
internal
spans
that
have
that
you
know
have
information
from
faraday
and
information
from
koala
and
so
forth.
D
Until
we
get
down
to
this
client
spam,
we
want
the
client
span
to
capture
like
all
of
that
context,
because
that
allows
us
to
do
things
like
inject
the
peer.service.
So
on
on
the
server
side.
We
have
this
nice
nesting
where,
like
a
rack,
adapter
can
create
a
span
and
then
middleware
things
can
can
simply
add
tags
to
that
span
or
modify
its
name
or
whatever,
so
that
we
can
refine
that
span
over
time,
but
the
nesting
goes
the
other
way
for
client-side
operations.
D
So
the
thought
I
had
here
was
actually
to
use
a
or
introduce
some
kind
of
http
client
context
for
these
http
related
gems
that
allow
us
to
actually
like
gradually
collect
context
on
the
way
like
on
the
call
chain
through
like
koala
faraday,
faraday,
middleware
and
then
ht
net
http,
and
then
the
net
http
instrumentation
would
take
all
that
contacts
that
have
been
collected
and
injected
as
tags
on
the
span
on
the
outbound
span.
D
A
This
sounds
like
a
reasonable
approach.
Actually,
it's
like,
as
far
as
I
know
like
this
is
this
is
unique.
This
is
the
first
time
I've
heard
of
this
scheme,
but
I
know
I
mean
I
know
we've
kind
of
talked
about
nested
client
spans
and
this
whole
kind
of
situation
before
this
was
kind
of
back
back
with
faraday
being
kind
of
the
first
culprit.
A
But,
as
you
point
out,
there
are
like
a
number
of
these
things
so
by
by
having
some
sort
of
standard
notion
of
a
thing
that
you
can
set
in
a
context
that
that.
A
D
So
I
mean
net
http
is
the
last
thing
and
typhus
is
the
last
thing
right.
Those
are
two
examples
of
the
last
things
in
that
chain,
but
it's
basically
anything
that
declares
itself
to
be
a
an
http
client.
Gem
would
really
be
the
last
thing,
whereas
faraday
isn't
really
that
faraday's
kind
of
this
layer
of
middleware
or
a
framework
for
injecting
middleware,
but
it
requires
wrapping
either
net
http
or
typhus
or
some
other
thing
at
the
end.
D
A
Kind
of
yeah-
I
I
generally
agree
with
that,
but
there
are,
as
always,
there
are
like
some
edge
cases
around
this.
I
guess
where,
like
you,
could
you
could
choose
to
not
use
net
http
instrumentation?
This
is
like
a
a
possibility
as
a
user,
and
you
could
only
pull
in
faraday,
for
example,
in
which
case.
A
I
think
the
decision
not
to
pull
in
that
http
is
also
very
questionable,
but
but
yeah
like
any
thoughts
on
on
that.
A
I
think
it's
more
not
to
reduce
the
number
of
spans,
although
you
could
possibly
do
this.
I
think
it
was
more
to
like
get
information
to
that.
To
this
fan,
that's
actually
making
the
outgoing
request,
so
you
can
decorate
that
span
with
the
most
appropriate
information
and
also
know
which
one
should
actually
be
the
clients
fan.
So
you
don't
end
up
with
like
client,
client,
client
server,
because
that's
kind
of
a
problem.
D
Yeah,
it's
also
like
I've
got
the
example
here
where
koala
would
tag
the
peer
services,
facebook
and
then
the
http
client
would
would
then
pick
that
up
and
add
it
to
its
span.
E
D
Then
yeah
grpc
is
interesting
and
one
of
the
I
believe
one
of
the
problems
with
open
census.
Instrumentation
was
you'd
end
up
with.
If,
if
you
made
a
client
request
to
like
a
google
service,
for
example,
you'd
end
up
with
and
you
enabled
open
census
tracing
in
grpc
you'd
end
up
with
all
these
spans
created,
like
you,
have
this
explosion
of
like
five
client-side
spans
related
to
the
grpc
tracing,
even
though,
from
your
perspective,
you're,
creating
the
client
spam.
E
A
Yeah,
I
I
do
like
the
idea
as
well.
I
think
there
is
kind
of
this
tricky
situation
of
like
figuring
out
what
is
really
the
client
span,
and
can
we
consistently
know
like
where
is
that
terminal
thing
so
yeah,
do
you
feel
like
there's,
maybe
a
little
bit
more
thinking
to
do
on
that.
D
I
don't
know
I
don't
have
enough
knowledge
of
the
http
ecosystem
in
ruby
and,
in
particular,
with
with
faraday
I've
just
seen
this
particular
example
as
problematic.
It's
like
how
do
you,
how
do
you
actually
implement
this
with
the
pieces
we
already
have,
and
the
answer
is
that
you
really
can't
effectively
do
it
at
the
moment.
A
I'm
definitely
interested
in
this,
so
I
think
it's
worthy
of
a
little
bit
more
discussion
like
I
think
it
might
be
early
to
like
say
thumbs
up.
A
Let's
just
go
and
do
this
everywhere
but
like
I
think
this
would
be
maybe
a
good
topic
to
bring
up
at
the
maintainers
meeting
on
next
monday
I'll
be
there
and-
and
I
can
bring
this
up
just
kind
of
see
if,
if
any
other
cigs
have
the
situation,
just
as
like
a
yeah
just
just
as
a
data
point
and
see
if
anybody
has
thought
about
this
and
has
any
ideas
around
this,
but
I
think
anything
that
we
can
come
up
with.
That
would
be
reasonable
and
cover.
A
D
There
are
other
interesting
examples,
so
things
like
elasticsearch,
where
it
like
it's
treated
in
the
spec
as
a
database,
but
you
talk
to
it
over
http,
that's
an
interesting
case
for
instrumentation
as
well.
That's
actually
where
this
is
coming
up
for
us.
We
internally
we
have
an
elastic
search
gem,
which
then
wraps
faraday
and
then
wraps
typhus,
so
yeah
the
instrumentation
for
that
gets
interesting.
A
Yeah-
and
I
think
so
I
mean
what
what
is
your,
what
is
the
desired
outcome
there?
Should
the
elastic
search
span,
be
the
terminals
fan
and
should
that
should
that
be
the
clients
fan
and
should
the
other
ones
be?
A
Okay,
cool
yeah.
I
will
I
will
at
least
put
something
on
the
agenda
for
the
maintainers
meeting
for
talking
about
things,
because
I
think
we're
not
alone
in
this
area,
but
I
think
exploring
what
this
means
for
elasticsearch
and
I
think
for
grpc
and
generally
anything
that,
like
is
using
http
as
the
underlying
transport.
But
the
thing
itself
could
be
is
a
candidate
client
span.
I
guess
so
most
like
any
http
based
database
would
be
in
this
category.
D
Cool
we're
a
couple
of
minutes
over.
I
just
wanted
to
get
thumbs
up
from
folks
on
cutting
a
new
release.
Today
is
everyone?
Okay,
with
that.
D
D
We've
completed
yeah,
I
don't
know
if
that's
true,
there's
the
other
one
that
I'm
putting
in
there's
the
otlp
compression
thing
that
wasn't
a
braking
change
that
I
merged
this
morning,
but
I
think
they've.
I
think
we've
had
a
few
other
changes
that
maybe
weren't
correctly
tagged
against
beta08
that
have
gone
in
since
the
last
release.
A
Yeah,
I
think
those
those
changes
are
actually
those
are
nice.
Those
would
be
nice
to
get
out
there.
The
the
current
span
stuff
moving
to
the
trace
module,
like
I'm,
I'm
a
pretty
big
fan
of
that
and
used
it
in
my
b3
implementation,
and
it
all
worked
quite
well
so
so
yeah
thumbs
up
on
on
the
release.
I
think.
B
Yeah,
you
need
to
hear
those
breaking
changes
that
like
because
I'm
trying
to
do
this
rails
instrumentation.
But
when
I'm
testing
my
test
app,
I
like
to
use
our
internal
wrapper
to
just
do
all
the
setup,
because
it's
too
easy,
but
it's
pointing
at
the
seven
release
and
then
my
local
fork
has
faster,
which
doesn't
work
because
of
that
change
that
isn't
in
so
this
would
be
really
nice
for
my
insanity.
D
Selfish
reasons
driving
yeah,
I
will
chase
up
the
things
that
we
committed,
that
weren't
tagged
against
beta
08
and
make
sure
that
we
tag
them
correctly
and
then
move
the
milestones
around.
So
we
get
like
a
beta,
09,
milestone,
etc,
etc.
So
I'll
do
all
that
cleanup
and
then
cut
the
new
release.
A
Yeah,
I
think
that's
fine,
maybe
just
make
a
little
bit
of
noise
in
the
getter,
that
you
made
a
release
and
there's
some
breaking
changes.
Just
so
that
you
know
people
there
won't
won't
be
shocked,
but
I
think
I
think
most
of
our
users
are
used
to
being
on
the
bleeding
edge,
but
so
we
yeah
being
being
as
clear
as
we
can
about
that,
we'll
spare
them
some
heartache.
I'm
sure.