►
From YouTube: 2021-02-16 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
A
B
B
B
There
was
kind
of
some
talk
in
the
beginning
about
just
generally
overhauling
the
way
that
they
cover
the
issues
in
the
beginning
of
the
meeting
and.
B
B
So
I
guess
for
those
of
you
that
don't
know
we'll
switch
we'll
skip
to
this
this
point
and
then
backtrack
just
a
little
bit,
but
the
spec
1.0,
the
spec
has
reached
1.0,
there's
been
a
1.0
and
a
1.0
or
there's
open
a
1.0.0
and
a
1.0.1
really
so
far.
So.
B
So
that
is,
that
includes
like
a
stable
tracing
signal.
Everything
else
is
still
experimental,
but
that
is
still
a
pretty
big
big
milestone.
So
now
I
guess
they're
going
to
announce
that
at
10
a.m
today,
which
is
a
little
less
than
an
hour
from
now.
B
I
guess
this
did
so
yeah.
So
now
languages
are
kind
of
working.
Their
way
towards
rc
different
different
cigs
are
in
kind
of
a
different
different
stages
of
of
readiness.
I
would
say
so
backtracking
here.
I
think
they
were
just
asking
the
gosig
when
they
think
they
might
have
an
rc.
B
It's
a
pretty
high
demand
language
and
I
think
that
kind
of
caught
that
sig
by
surprise
a
little
bit
that
they
were
asking
about
an
rc.
So
there
was
just
a
discussion
about
how
how
to
better,
align
those
things
and
better
align
any
kind
of
expectations
there.
I
guess.
B
I
think
one
suggestion
was
to
have
some
sigs
kind
of
sign
up
to
be
like
on
the
bleeding
edge
of
the
spec
as
one
potential
solution.
B
It
wasn't
his
question,
wasn't
specifically
about
this
pr,
but
this
pr
is
kind
of
an
example
of
such
things
where,
like
basically,
there
are
some
rules
for
when
apr
can
merge
the
spec.
I
think
it
needs
to
have
like
four
approval
for
approvals.
It
needs
to
be
open
for
like
two
business
days
or
something
like
that,
and
this,
like
particular
pr
that
he
points
out
as
an
example,
has
that,
but
there's
like
kind
of
one
slightly
dissenting
opinion
on
it
and
he's
just
like
unsure
of
what
to
do.
B
It
was
kind
of
situational,
but
if,
if
the
thing
that
needs
to
be
addressed
is
kind
of
like
something
that
has
been
talked
about
like
at
length
before
and
it's
kind
of
well,
that's
a
lost
cause.
But
it's
you
know
it's.
It's
been
kind
of
talked
about,
and
people
are
generally
on
on
the
same
page
with
what
to
do
kind
of
mention
that
and
see
that,
if
that's
enough
to
move
things
forward,
the
other
strategy
is
to
kind
of
look
at
the
thing
that's
unresolved
and
potentially
see.
B
B
I
should
have
grouped
this
one
with
the
1.0
talk,
but
opentelemetry.net
1.0
release
is
ready
to
be
announced.
B
The
next
question
was
that,
basically,
this
is
what
this
was
a
metrics
question
and.
B
It
seems
seems
like
the
use
case
is,
as
I
understand
it
was
that
there
is
some
metadata
that
is
available
when
a
container
when
a
container
is
dying.
B
There's
really
not
like
a
metric
related
to
it,
but
it's
kind
of
like
stuff
that
would
end
up
being
resource
related
data
that
this
user
kind
of
wants
to
send
wants
to
send
resource
metadata
without
metrics.
B
That
kind
of
the
follow-up
is
that
there
are
kind
of
like
some.
There
is
some
talk
about.
B
I
think
a
metric
called
up
certain
up
metrics
for
resources
there's,
so
that
would
be
like
a
true
or
false
or
zero,
or
one
kind
of
thing
that
gets
recorded
occasionally
for
a
resource
or
like
a
present
metric.
I
think
generally.
The
idea
is
that
there
should
be
some
sort
of
metric
that
accompanies
the
thing
that's
being
recorded.
There
might
be
like
an
appropriate
one.
B
Some
of
those
might
be
in
the
process
of
being
developed
like
this
up
or
present
metric,
if
not
like,
they
were
saying
that
this
person
should
kind
of
participate
in
the
discussion
of
these
metrics
because
it
sounded
like
his
use
case,
was
kind
of,
at
least
in
that
general
area.
B
So
the
next
thing
was
we
had
this
discussion
several
weeks
ago
and
we
rediscussed
it
over
here.
B
But
this
was
the
thing
that
kind
of
spawned
that
discussion
it.
This
isn't
totally
the
ask,
but
basically
there
was
the
realization
that,
with
a
lot
of
modeling
and
instrumentation
that
cigs
are
kind
of
running
into
some
interesting
problems
and
solving
them
all
themselves
in
slightly
different
ways.
B
So
we
kind
of
talked
about
this
one
in
the
context
of
like
rack
and
rails.
It's
like
we
have
rack
rack,
will
create
your
your
server
http
span
and
then
rails
will
kind
of
decorate
that
span.
Other
sigs,
for
example,
will
may
take
another
approach
where
rack
would
have
its
own
span
rails
would
have
its
own
span
and
kind
of.
Similarly
for
things
that
start
nesting
up
on
http
requests.
It's
like
is
it?
B
Can
you
have
nested
client
spans?
How
do
you
make
sure
that
the
last
one
ends
up?
If
not,
how
do
you
make
sure
that
the
last
one
in
the
nesting
is
the
actual
client
span?
B
Does
it
really
mean
that
your
fans
are
too
granular
and
you
should
really
be
adding
a
lot
of
this
nest
and
stuff
as
events
blah
blah
blah
it's
just
kind
of
a
there?
There
are
many
approaches
that
can
be
taken
to
some
of
these
situations,
but
there's
not
like
a
lot
of
guidance
or
structure
around
which
approaches
to
take.
B
So
I
think
the
ask
was
really
like.
Should
we
start
having
these
discussions
a
little
bit
more
because
while
tracing
is
stable,
like
instrumentation
is
still
kind
of
all
experimental?
I
guess
and.
B
Yeah,
I
think,
in
order
to
call
instrumentation
stable.
Some
of
these
questions
probably
need
to
be
answered.
B
Well,
I
guess
just
complete
that
previous
thought,
like
I
think.
Yes,
there
will
be
more
discussions
about
this.
I
wasn't
sure
this
is
going
to
spin
off
as
a
separate
meeting
or
not,
but
I'll
keep
an
eye
on
it
if
it
is
and
try
to
pay
attention
there
or
if
it
will
just
kind
of
be
part
of
the
spec.
B
B
All
right,
second
to
last
item
increasing
coverage.
Nikita
was
asking
about
about
really
this
kind
of
long-term
goal
of
open
telemetry.
B
And
then
kind
of
another
kind
of
meeting
management
question.
I
think
this
probably
came
up
as
a
result
of
this
meeting.
Sometimes
we
get
into
the
weeds
on
certain
issues
and
it
kind
of
leaves
not
a
lot
of
time
to
talk
about
other
stuff,
so
just
kind
of
at
an
ask
to
do
a
better
job
with
time
management
and
if
there
is
something
that
is
a
larger
discussion,
find
some
way
to
kind
of
break
it
out
of
the
meeting
so
that
everything
else
can
be
gotten
through.
B
I
don't
know
any
questions,
comments,
concerns
about
stuff
that
went
on.
A
Here,
cool:
well,
I
guess
one
thing:
this
is
the
first
I've
been
hearing
about
this
trace
data
model
and
you
know
there's
also
the
metrics
data
model
referenced
here
as
well.
Is
this
a
new
thing
and
can
you
describe
the
sort
of
discussions
that
are
happening
in
terms
of
defining
a
data
model.
A
B
The
fact
that
there
are,
I
don't
know
like
I
think,
what
are
we
calling
this
thing
here.
B
At
least
the
way
I've
seen
this
discussed,
it's
been
less
about
like
a
tracing
data
model
and
more
of
like
an
instrumentation
guideline,
instrumentation
kind
of
modeling
question
and
yeah.
Basically,
john
was
one
who
put
this
thing
on
the
agenda
and
he
just
wanted
to
call
attention
to
this
again,
and
he
said
you
know
when
we,
when
we
talked
about
this
at
a
spec
meeting
roughly
like
a
month
ago,.
B
Framework
for
how
you
structure,
instrumentation
kind
of
between
cigs
and
handle
some
of
these
situations-
and
we
kind
of
talked
about
like
as
this
kind
of
came
up.
B
We
we
talked
about
some
strategies
like
I
brought
up
like
this-
is
particularly
this
particular
example
is
about
an
http
request,
and
these
are
the
potential
things
that
you
want
to
record
and
I
think,
as
java
is
doing
it
like
all
of
these
end
up
being
separate
spans
and,
like
you
end
up
potentially
having
like
five
different
client
spans,
which
I
think
the
the
real
question
was.
Is
that
even
allowed
by
the
spec?
It
seems
to
indicate
that
you
should
only
have
one,
but
that
wasn't
even
clear.
B
So
I
think
I
think,
for
java
you
might
actually
get
like
five
client
spans
in
this
situation,
which
is
probably
going
to
be
a
problem
with
a
lot
of
tracing
back
ends.
So
in
this
conversation
I
mentioned
like
some
of
these
things
like
at
least
these
last
three.
I
feel
like
those
look
really
close
to
probably
events
on
a
span-
I'm
not
positive
there,
but
that
that's
one
way
to
look
at
it.
These
other
ones,
I
feel
like
they
kind
of
look
a
little
bit
like
faraday
and
that
http
it's
like.
B
But
I'm
I
did
mention,
I
mentioned
how
we
handle
this
for
koala
kind
of
by
having
a
a
predefined
key
in
your
context,
for
some
attributes
that
you
want
to
attach
to
the
to
what
is
ultimately
going
to
be
the
client
span.
B
So
the
clients
fan
knows
to
look
there
and
you
can
kind
of
decorate
your
client
spam
with
stuff
that
was
actually
kind
of
created
before
the
span
was
and
and
that's
one
approach
and
then
kind
of
just
mentioned
the
our
rack
situation,
where
we
have
a
way
to
kind
of
enrich
the
https
fan.
So
you
don't
have
to
you,
don't
necessarily
have
to
create
nested
spans,
and
you
end
up
with
a.
I
think
really.
B
Rather
than
probably,
you
know,
the
the
path
name
or
whatever
the
best
thing
we
can
get
out
of
rack
is
without
writing
some
sort
of
code
to
quantize.
It.
A
Are
we
going
to
see
a
more
formalized
data,
modeling
kind
of
effort
going
on
as
part
of
either
the
spec
sig
or
a
another
sig
yeah?
I
see
earlier
in
the
spec
sign
notes.
There's
you
know
they
talk
about
overhauling
the
labeling
system
and
having
separate
roadmaps
for
tracing
metrics
api
metrics
data
model
in
there,
and
so
I
wondered
if
like
tracing
data
model,
is
a
separate
thing
from
like
the
tracing
api.
B
More
than
anything,
the
way
this
came
up
was
it
was
like
a
a
reminder
that
we
need
to
get
some
effort
started
behind
all
of
this.
So
I
think
I
think
the
short
answer
is
it's
to
be
determined
what
what
shape
this
will
take,
but
but
yeah,
I
think,
like
there
is
some
some
overhauling
of
of
all
of
the
kind
of
project
management
right
now.
B
I
think
the
the
thing
that
you
were
pointing
to
here,
like
the
the
labeling
system,
is
kind
of
like
the
labeling
of
issues
and
everything
how
this
was
all
triaged.
It
was
like
a
good
enough
system
to
get
us
to
tracing
1.0,
but
I
think
there
are.
B
B
My
gut
feeling
is,
I
feel,
like
that,
could
get
pretty
complicated,
but
both
in
the
discussions
and
the
the
guidelines
that
end
up
getting
drafted
out
of
that.
But
we'll.
B
B
A
I
did
get
a,
I
think
I
brought
it
up
last
week,
it'd
be
really
good
to
have
some
people
take
a
look
at
the
bunny
instrumentation
pr
and
the
author
of
that
pr.
Also
pinked
me
on
guitar
late
last
week
I
think,
or
maybe
over
the
weekend
asking
like
to
take
another
look
at
it,
so
we've
been
letting
that
one
sit
for
quite
a
while
it'd
be
good
to
get
back
time.
B
B
Yeah
that
has
been
open
for
a
bit,
the
other
one
that
hasn't
opened
for
a
bit
that
I
at
least
got
some
eyes
on
was
the
jaeger
propagator.
I
see
francis
that
you
were
able
to
update
this
yesterday,
so
I
can
yeah,
I
don't
know
yeah.
I
forgot
to
re-request
on
github.
B
No,
it's
fine.
I
will
get
another
look
on
it.
I
did
see.
I
saw
some
changes
came
in
and
that
you
have
this
comment
here
about.
B
About
squashing,
I
would
say,
like
you,
don't
have
to
worry
about
that,
because
this,
like
all
pr's,
get
like
squash
and
merged
on
the
way
in
anyways.
So
unless
you're
really
really
concerned
about
well,
something
else
like
this
will
all
turn
into
one
commit
in
the
end.
So.
B
C
So
I
mean
I'm
that's
cool.
I
I
feel
like
I,
it
just
made
me
from
my
own
benefit,
be
useful
to
understand
conceptually
what
like.
So
when
you
look
at
so
the
j
the
jager
spec
we've
been
using,
doesn't
mention
open,
telemetry
at
all
sure
it
talks
about
how
open
tracing
defines
two
plate,
two
formats
for
plain
text,
editors,
http,
headers
and
text
map.
My
understanding
correct
me.
If
I'm
missing
something
is
a
text.
Map
injector
and
extractor
are
just
general
right
like
it's
for
just
text
manipulat.
C
You
know
it's
basically
hash
or
fine,
but
it's
like
you
could
send
it
over
http,
but
you
might
also
send
it
using
some
other
mechanism.
So
I
I
almost
wonder
I
don't.
This
is
not
in
the
hotel
spec,
but,
like
you
know,
you
could
imagine
having
an
hp
header
injector,
an
extractor
which
is
the
text
map
injector
instructor
with
this
extra
little
encoding.
B
Yeah,
so
in
in
open
tracing,
these
were
distinct
formats
in
open
telemetry.
I
think
it's
a
little
bit
more.
B
The
primary
use
case
for
these
is
to
send
send
contacts
in
http
requests
so
like,
if
it's
possible,
that
you
could
create
something
that
would
be
invalid
for
http
transport
yeah.
That
seems
like
it's
a
pretty
big
risk
for.
C
Definitely
I
mean
it
should
be
somewhere.
There's
no
question:
yeah
yeah!
No,
I'm
just
I'm
just
now.
Seeing
that
again,
like
the
part
in
the
in
the
hotel
spec,
which
is
like
it's
usually
an
hp
request,
so
we're
just
sort
of
like
go
with
the
default
there
and
then
like
the
key
value.
Pairs
must
only
consist
of
I'm
looking
at
the
hotel,
spec
and
under
propagators,
and
it's
like
yeah.
The
key
value
pairs
must
only
consist
of
usc
characters
that
make
a
valid
hp
header
fields.
C
Yeah.
Okay,
I
can
add
that.
B
Cool
yeah
and
for
the
most
part
like
if
your,
if
your
keys
and
values
are
very
uninteresting,
the
http
encoding
of
them
will
be
the
same
as
the
text
map
encoding.
Of
course,
yeah
yeah,
it's
just
as
you
start
to
like
get
into
edge
case
world.
That's
where
things
get
a
little
more
interesting
and
the
the
url
encoding
will
will
save
you
so.
B
D
D
We
ran
into
it
like
with
our
internal
instrumentation
implementation,
that
fairly
closely
mimics
the
open,
telemetry
one
and
essentially
what
we
believe
is
happening
if
someone's
killing
their
their
worker
pod
for
sidekick
jobs
properly
and
the
main
threads
getting
killed,
and
when
the
exporter
tries
to
restart
on
fork
or
reset
on
fork.
D
B
Just
to
remind
myself
like
I
know,
we
have
a
mechanism
to
kind
of
record
some
metrics
from
from
the
export
pipeline,
and
but
we
really
don't
have
like
an
implementation
backing
this.
This
is
just
kind
of
a.
B
Specialized
thing
that
if
you
know
what
you're
doing
you
can
use
for
now
until
we
kind
of
have
one,
am
I
recapping
that
generally
correctly.
A
Yeah,
that's
that's
correct
because
we
don't
have
a
metrics
implementation,
api,
sdk,
etc.
We
like
in
production,
certainly
shopify
in
production.
We
need
some
way
of
getting
these
metrics
out
of
the
exporter
pipeline
and
this
is
our
hopefully
future
proof
way
of
doing
that.
A
It's
cool.
We
would
also
like
to
propose
a
specific
metric
names
and
attributes
or
labels
as
something
at
the
spec
level,
so
that
we
end
up
having
like
reporting
the
same
metrics
from
the
otlp
exporter
in
every
language
implementation.
A
Thread.New
blows
up
inside
mri,
mri
checks
to
see
whether
or
not
the
main
thread
is
still
alive,
and
if
it's
not
alive,
then
it
raises
a
thread
error
rather
than
creating
a
new
thread.
So
it
doesn't
allow
you
to
create
a
new
thread
if
your
main
thread
is
dead,
so
this
isn't
really
a
problem
for
us.
I
mean
it's
happening
during
termination
anyway,
but
it's
sort
of
an
annoying
because
it
ends
up
showing
up
in
you
know,
bug
snag
logs
or
whatever
and
people
come
knocking
saying.
A
B
B
D
Other
than
that,
I
have
a
pr
that
I
think
should
be
going
in
soon,
just
to
add
those
hooks
to
the
otlp
exporter,
which
I
don't
post
last
week
for
the
week
before,
just
adding
a
mechanism
for
us
or
anyone
to
trace
their
export
pipeline.
If
they
choose
the
default,
behavior
will
be
to
leave
it
untraced.
D
D
B
I
think
this
is
fine.
We
we
talked
about
it
pretty
pretty
comprehensively
last
time
but
yeah
I
see
it's
been.
D
And
then
I
have
a
couple
prs
ones
to
draft,
but
then
once
I
think
ready,
probably
for
some
additional
eyes,
it's
the
http
client
gem
instrumentation.
I
think
it's
a
little
bit
lower.
It's
a
little
bit.
It's
been
sitting
since
before
the.
D
Holidays,
so
I
think,
there's
potentially
still
a
little
bit
of
discussion
to
happen
around
a
connect
span
being
traced
just
because
it's
a
little
bit
weird,
it
could
be
an
event,
but
in
the
case
of
at
least
in
the
case
of
net
http,
I
think
that
it
needs
to
be
its
own
span,
which
is
the
draft
pr
I
have
up
is
to
add
that,
whether
or
not
like,
I
think
it
should
be
a
client,
but
we
don't
have
request
headers
to
inject
into
so
it's
kind
of
awkward
in
the
sense
that
I
don't
think
we
can
easily
continue
the
trace.
D
The
main
reason
I
actually
want
this
instrument
to
just
well
transparency
is
that
I
want
to
instrument
the
google
api
gem
following
this
getting
in,
and
I'm
hoping
that
maybe
I
can
guilt
daniel
a
little
bit
to
give
hotel
official
support.
Google
api
gem
that
I
think
he
maintains.
A
But
yeah
the
google
api
jam
currently
uses,
or
it
supports
instrumentation
with
open
sensors
internally
at
shopify,
we've
leveraged
those
hooks
to
instrument
it
with
open
telemetry
instead
or
also
with
our
custom,
our
old
kind
of
custom
tracing
thing
so
yeah.
We
really
love
it.
If
the
the
upstream
google
api
client
used
open
telemetry
for
instrumentation
instead.
D
We
find
that,
like
instrumentation,
really
valuable
as
a
default
in
the
company,
just
lots
of
different
applications
using
storage
api,
it's
different,
just
google
apis
and
having
it
instrumented
by
default.
You
can
like
in
our
service
map
we
can.
We
have
a
node
for
google
and
you
can
quite
easily
see
all
the
different
services
at
shopify
that
communicate
directly
with
google
and
if
any
of
them
are
having
any
problems.
D
So
it's
it's
a
really
nice
thing
to
have
for
us,
so
my
goal
is
to
get
to
that:
try
to
get
open
telemetry
to
have
tracing
for
the
google
api
gym,
and
this
is
kind
of
a
required
step.
So
if
anyone
has
any
bandwidth
to
look
at
this
one,
it
is
I
kind
of
mentioned.
It
is
a
bit
of
a
shameless
port
from
our
internal
instrumentation,
which
we
are
using
in
production
on
all
our
services.
So
I
know
at
very
least
that
this
approach
works,
so
that
adds
any
confidence.
D
Sense,
I
do
just
as
a
side
following
the
this
and
the
google
api
instrumentation,
I'm
gonna
start
working
on
active
record
kind
of
a
missing
piece
for
us
right
now.
I've
started
I've
have
one
service
on
open,
telemetry,
ruby
internally
right
now,
and
I'm
looking
to
push
more.
But
I'd
like
to
get
the
active
record
instrumented
before
I
get
too
many
more
on
open,
telemetry.
B
B
E
Yeah,
I
would
say
for
donut
tackle
actor,
but
not
to
say,
oh
hello,
everyone
why
hello
there
oh
active
support.
It's
basically
just
like
it's
a
way
to
sneak
in
a
really
nice
general
active
support.
Helper
class
is
active
records.
Sort
of
I
think.
If
I'm
thinking
about
what
datadog
does,
I
think
we
mostly
leverage
active
support
when
we're
doing
active
record.
I
don't
know
if
they
need
to
be.
E
I
genuinely
don't
know
if
they're
always
tightly
coupled,
but
you
might.
I
don't
know,
I
don't
have
strong
opinions
if
it
turns
out
there's
a
better
way
to
instrument
activerecord,
but
you
might
find
yourself
just
being
like.
Oh
wait.
A
second.
This
is
low-key,
like
90
percent
of
what
I
would
do
for
for
active
view.
So
I
should
like
you
know
just
generalize
the
active
support
stuff
into
a
helper
because
it
tends
to
yeah
a
lot
of
stuff
ends
up
being
active
support.
A
Yeah,
I
mean
we've
discussed
this
previously.
The
concerns
with
active
support
are
really
what
happens
when
you
have
a
bunch
of
subscribers
to
the
same
event,
and
one
of
them
raises
an
error.
A
The
others
don't
actually
get
the
notification.
So
if
you're,
relying
on
it
to
actually
pair
kind
of
starting
a
span
and
finishing
the
span,
it's
possible
for
those
to
effectively
get
out
of
sync,
so
you'll
end
up
with
unfinished
spans
and
that
can,
depending
on
the
complexity
of
your
instrumentation,
that
can
lead
to
some
interesting
weirdness.
A
We
have
a
lot
of
stuff
in
our
old
custom,
instrumentation
library
that
worked
around-
that
I
don't
want
to
reach
for
active
support
notification
as
the
first
tool
for
instrumenting
rails
or
instrumenting
other
things.
I'd
prefer
to
do
it
some
other
way
wherever
possible,
but
yeah.
I
understand
it's
a
it's
a
convenient
thing
to
do
and
something
that
a
lot
of
people
do.
E
A
E
A
Mean
we've
we've
discussed
this.
We
discussed
this,
like
I
don't
know,
four
or
five
years
ago,
with
raphael
on
the
rails
team
and
at
the
time
it
was
like
this
is.
This
is
not
going
to
change
right.
This
is
the
behavior
of
active
support
notifications
and
you
just
have
to
deal
with
it
actually.
A
So
we
dealt
with
it,
but
I
don't
know
world
is
changing.
E
A
Yeah
things
may
have
changed
since
then.
I
thought
I
looked
at
it
again
recently
and
the
latest
version
of
rails
and
nothing
had
practically
changed
there,
but
maybe
they're
more
receptive
now
to
to
making
that
change.
I
don't
know.
E
No,
no,
I
was
making
a
joke,
but
yeah,
obviously
yeah
anyway
cool
awesome.
I'm
I
should
review
the
http
client
thing,
though
that's
what
I
think
is
more
actionable
here:
cool
thanks.
As
always
robert.
D
There's
also
a
I'll
put
on
a
draft
today,
but
there's
a
change
to
net
http.
There's
quite
a
bit
overlap
between
this
instrumentation
and
the
nhtp.
The
tests
are
almost
identical.
I
think
I
just
copied
them
almost
verbatim
between
the
two
gems
but
yeah.
The
idea
here
is
just
tracing
the
k'nex
band.
D
D
I've
noticed
a
few
services
of
getting
a
lot
of
value
out
of
this,
because
some
of
the
requests,
certain
external
services,
are
not
failing
on
the
request,
they're
failing
on
the
connect
and
without
the
connect
being
traced,
there's
just
no
evidence
in
our
traces
that
something
went
wrong
with
the
connection.
It's
just.
It's
completely
lost,
whereas
when
we
added
and
we've
I've
seen,
a
few
services
actually
immediately
pulled
a
lot
of
value
out
of
it
because
they're
seeing
that.
Oh
all,
our
connects
are
timing
out
too,
and.
E
A
Yeah,
I
was
initially
pro
jbd's
approach
of
adding
connects
as
events
on
a
span,
but
robert
actually
pointed
out
that
it's
possible
to
connect
independently
of
sending
the
request,
so
it's
actually
useful
to
trace
in
isolation,
otherwise,
you'd
end
up
with
events
on
the
parent
span.
Instead
of
the
request
span,.
D
A
This
kind
of
gets
back
to
the
data
modeling
question
right
with
all
the
the
nested
client
spans.
A
A
One
possible
problem
with
that
is
that
back
ends
might
get
confused.
They
might.
If
you
had
something
where
you
did
a
connect
on
every
request,
then
you
could
end
up
double
counting
the
client
spans
for
that
service
on
the
client
side,
and
you
only
get
a
single
one
on
the
server
side,
so
that
could
skew
metrics
weirdly
if
you're
building
a
service
graph
or
something
I
don't
know
what
the
practical
effect
of
it
would
be.
But
it's
a
possible
problem.
D
A
B
But
there
was
a
lot
of
recognition
of,
but
that's
hard.
So
we
need
to
have
some
more
discussions
to
figure
out
exactly
the
the
way
that
should
work
or
see
if
it
even
can
work
that
way.
All
the
time.
A
I
just
wanted
to
jump
into
very
briefly.
I
think
we
should
put
together
a
road
map
for
release
candidate
and
a
1.0
release
curious
how
people
feel
about
that,
and
is
there
a
timeline
we
think
we
should
be
aiming
at
to
get
that
out.
Remember
like
the
biggest
blocker
right
now
from
spec
compliance
perspective,
at
least
is
the
zipkin
exporter.
I
think
nobody's
working
on
that
right
now,
but
beyond
that
I
mean
there's
spec
compliance
and
then
there's
actually.
What
do
we
think
justifies
a
1.0
release?
B
E
A
E
Yeah
yeah,
my
dog
dog,
ate
my
homework
type
situation.
I
don't
know
literally
adopt
a
dog
to
kill
two
words.
If
I
want
one
stone,
my
wife
will
be
happy
yeah.
I
think
I'm
like
really
big
into
like.
Let's
try
to
push
one
point
out,
it
doesn't
matter
it's
like
there's,
always
positive
momentum.
We
should
just
like
rush,
but
I
also
don't
know
what
the
trade-offs
of
that
would
be.
But
that's
my
two
senses.
A
I
also
think
it's
nice
that,
like,
as
far
as
you
can
tell
probably.net,
is
the
one
that's
ready
to
go
and
some
of
the
other
you
know
big
languages
go
and
so
forth
are
maybe
a
little
taken
aback
by
needing
to
have
an
rcn
1.0.
So
it
would
be
nice
for
ruby
to
get
out
there
even
potentially
ahead
of
some
of
these
other
languages,
but
regardless
to
to
follow
pretty
quickly
on
the
footsteps
of
the
major
languages,
not
that
I
have
any
dislike
for
erlang
at
all.
A
But
it's
sad
to
me
that,
like
you
know,
erlang
is
always
promoted
there
in
the
list
of
like
major
languages
for
for
open
telemetry
and
ruby
is
not
so.
E
It
definitely
from
from
what
I've
found
just
working
with
end
users
or
having
to
deal
with
calls
like
having
a
clearer
story
around
being
like
these
languages
are
1.0
not
like,
or
on
rc.
You
can
not
like
hey,
it's
really
close
and
whatever,
and
the
spec
probably
won't
change,
but
these
are
the
environment
variables
you
might
want
to
keep
an
eye
on
like
is
it
makes
life
a
lot
easier,
so
yeah?
I
think
it
just
generally
will
help
with
adoption.
If
you
can
cut.
A
Yeah,
this
is
the
old
rc
milestone.
This
is
like
this
is
what
we
had
a
year
and
a
bit
ago.
D
A
Yeah,
I
think
we've
been
working
on
this,
a
while
cool.
We.
B
So
we
should
retool
our
our
1.0
rc,
so
I
think.
B
All
right,
so
we
know
that
we
have
zipkin
exporter.
I
feel
like
there
are
a
few
things
that
we've
talked
about,
that.
Maybe
we
didn't
issue
exactly
yet.
So
I
know
like
we
talked
about
a
propagators
should
have
implement
fields
technically
yeah,
so.
A
I
have
a
pr
kind
of
I
haven't
pushed
it
up
yet,
but,
like
I
have
a
pr
in
progress
for
that
refactor
I'll
try
to
get
done
soon,.
B
No,
it's
there's,
there's
no
problem,
it's
cool
that
it's
in
progress.
I
was
just
yeah,
so
we
should
track
it.
On
my
mind
is
a
thing
that
was
yeah
missing
from
the
spec
compliance
that
is
also
missing
from
from
issues
so
yeah.
I
guess.
B
We
should
make
this
milestone,
we
should
work
towards
it.
We
should-
I
think
you
mentioned
this
last
week,
francis,
but
we
should
all
kind
of
just
take
a
look
at
what
we
have
and
just
make
sure
there's
no
glaring
errors
that
we
should
fix,
but
this
is
all
going
to
be
part
of
our
rc
process.
I
guess
is
to
hey
reach,
spec
compliance
and
then
b
just
kind
of
make
sure
that
we're
happy
with
everything
it's
working
and
once.
A
Then
we
have
our
1.0
right.
So
do
we
feel
like
release
candidate
is
mostly
targeting
spec
compliance
and
then
1.0
is
you
know,
sanity
check
and
polish?
You
know
docks
or
whatever.
B
B
There
may
be
one
or
two
rcs
after
that,
where
we
kind
of
go
through
things
to
find
tooth
comb
and
find
that
maybe
something
wasn't
totally
implemented
correctly
or
we
need
to
fix
something
here
or
there,
but
once
we've
kind
of
gotten
once
we
are
reasonably
confident
that
what
we've
done
is
correct
and
as
far
as
we
know,
bug
free.
Then
we
go
to
one
point
on.
A
Okay,
sorry,
we've
got
like
a
minute
left,
so
I
just
want
to
briefly
mention.
I
wonder
if
it's
worth
doing
a
an
update
to
the
readme
that
lists
all
the
instrumentation
we
currently
have
and
lists.
Instrumentation
we
know
is
working
like
you
know.
A
Somebody's
working
on,
like
robert,
has
in
his
queue
or
whatever
and
then
list
instrumentation
where
we
know
there's
demand,
but
nobody
has
plans
to
work
on
over
the
moment
so
where,
where
we'd
like
some
help,
the
reason
I
bring
that
up
is
they
think
there
was
mention
of
like
postgresql
in
the
gitter
channel
and
they've
been
queries
as
well
about
you
know
the
rails
instrumentation
for
example,
and
some
other
things
so
just
I
feel
like
it'd,
be
useful
to
have
something
up
front
for
people
to
read
to
see
what's
currently
instrumented,
so
they
don't
need
to
understand
everything
about
the
the
implementation
and
the
structure
of
the
repo
in
order
to
figure
out.
B
Yeah,
I
I
think
that
makes
sense.
I
don't
know
that
I've
seen
this
in
any
of
the
other
repos
and
I
think
it
ends
up
being
kind
of
this
research
mission,
where
you
have
to
really
dig
through
the
repo
to
figure
out
what's
there,
but
I
think
people
coming
to
the
project
would
appreciate
it
being
on
the
readme,
and
I
see
no
harmony.
C
Great
I'll
I'll
make
a
little
issue
and
then
I'll
just
attach
myself.
C
B
B
All
right,
I
have
another
meeting
to
run
to
you.
So
did
you
want
to
take
a
stab
at
putting
together
the
the
rc
or
yeah
sure
sure
right,
that'd
be
great.
B
Cool
so
yeah,
I
know:
there's
we
talked
about
a
few
pr's
that
need
eyes,
I'll,
look
at
jaeger,
bunny
and
then
the
http
client
stuff.
That's
out
there
cool
thanks
all
right.