►
From YouTube: 2020-09-22 Spec SIG
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
A
B
B
A
A
A
A
D
D
D
D
D
D
Cool,
so
I
guess
we'll
do
the
usual
and
I'll
recap:
the
spec
sig,
and
then
we
can
kind
of
start
going
through
through
our
issues.
Next
milestone.
All
of
that.
D
Yeah
right
now,
I
think,
like
the
priority
is
still
like
these
p1
issues
around
around
the
tracing
api
things
seem
to
be
moving
along
fairly
well,
like.
D
Yeah,
there's
there's
always
a
lot
of
talk
about
dates.
I
don't
know
how
much
it
makes
sense
to
to
recap
exactly
all
the
dates
and
how
accurate
all
the
dates
are.
But
I
know,
like
you
know
like
the
overarching
goal
is
like
everyone
would
feel
super
comfortable
if
we
ga
to
buy
kubecon
north
america,
if
that
is
even
a
thing
in
in
our
current
world,
but
I
think
there
might
be
dates
for
such
an
event,
and
I
think
that's
that's
november-ish.
D
So
I
think
you
know.
That
means
that
the
spec
will
have
been
stable
way
before
that,
so
that
cigs
have
sufficient
time
to
implement
all
of
the
things,
but
I
think
that's
kind
of
like
the
at
least
the
aspirational
milestone
behind
all
this
stuff.
That
looks
like
november
17.
D
yeah,
and
I
think
that
sounds
about
right.
So
so
that
would
be
having
like
everything
stable
for
tracing
and
then
hopefully
having
sdks
that
that
implement
that.
D
And
I
don't
know
if
any
of
that
is
like
official
official,
you
know
deadlines
or
timelines,
but
I
think
that's
like
the
aspirational
thing
behind
and
at
least
in
a
lot
of
people's
minds.
D
So
read
into
that
date
too
much,
but
I
think
that's
kind
of
generally.
What's
what's
going
on
there,
I
think
all
of,
like
the
main
issues
are
being
dealt
with
like
there's
somebody
working
on
them
or
there's
a
pr
open
for
them.
So
things
are
looking
good
there.
D
There
are
still
a
couple
of
ongoing
things
like
is
null
a
valid
span,
attribute
value
or
not,
and
I
think
this
issue
has
been
going
on
for
a
while.
I
think
I
brought
it
up
after
the
last
several
meetings.
D
I
think
there's
like
some
contention,
whether
like
null
is
meaningful
or
null
is.
Basically,
I
tried
to
assign
a
string,
but
really
I
I
wasn't
careful
and
accidentally
assigned
a
null
like.
Is
that
really
valuable?
And
then
there's
this
other
bizarre
proposal
that
actually
just
setting
it
to
null
will
delete
the
attribute-
and
I
think
people
unanimously
well
almost
unanimously-
do
not
like
that
semantic
because,
like
it
does,
I
think
yeah
I
in
this
discussion
there
was
there
were
a
couple
of
conversations
that
were
happening.
D
Some
of
them
were,
you
know
null
if
it
makes
sense,
but
not
in
all
if
it's
kind
of
like
an
error
null
by
accident,
intentional
null
makes
sense.
No
by
accident,
maybe
doesn't
make
sense,
and
I
think
the
other
thing
was.
D
Do
we
really
have
to
decide
this,
and
could
we
punch
this
to
later
and
as
long
as
null
doesn't
delete
a
thing,
you're
free
to
expand
the
values
to
include
null
in
the
future?
So
I
think
people
are
continuing
to
hash
that
one
out,
but
yeah,
ultimately
I'll
be
finding
their
way
like
a
a
no
by
accident
is
not
going
to
kill,
kill
a
trace
and
you
can
go
back
and
fix
it.
So
I
don't
think
it's
worth
shedding
too
many
tears.
D
E
Yeah
looking
for
it
normally
with
with
these
things,
they
are
nullable
right.
Most
of
the
stuff
in
otlp
is
optional.
E
Is
optional,
or
maybe
the
thing
here
is
that
they
want
to
support
an
explicit
null
type.
So
you
kind
of
have
a
thing
that
it's
like.
The
value
is
not
absent.
It's
explicitly
null,
which
is
just
kind
of
weird.
D
D
So
the
next
thing
I
discussed
was
this
issue
that
a
that,
when
using
the
start
span
api
start
span
and
friends,
we
have
a
couple
of
others
or
yeah.
I
think
we
have
two
others
that
are
similar,
usually
well,
if
you're
going
to
explicitly
manage
a
parent
historically,
that
would
be
either
like
a
span
context
or
a
or
a
span
in
the
old
old
days
before
maybe
january
of
this
year.
D
But
then
there
was
other
66
and
this
kind
of
drive
to
lift
context
up
to
like
a
higher
level,
make
it
a
top
top-level
kind
of
concept,
and
in
doing
that,
it
makes
it
almost
impossible
that
you
would
ever
have
just
kind
of
a
random
span
context
lying
around,
and
there
are
kind
of
future
plans
around
what
things.
What
things
you
might
want
available
to
the
export
pipeline
to
like
span,
processors,
etc.
That
might
come
from
the
context,
but
also
with
the
current
span
in
in
the
current
context.
D
So
because
all
this
is
somewhat
important,
I
think
well
yeah.
There
has
been
some
discussions
about
only
allowing
explicit
parents
to
be
a
context,
and
if
you
use
the
inspan
method,
which
I
think
the
majority
of
our
instrumentation
actually
uses,
I
think
it's
very
rare
that
we're
using
start
span
directly.
D
It
will
kind
of
implicitly
take
the
current
context.
It'll
take
the
span
out
of
the
current
context
as
as
the
parent
so
kind
of
behind
the
scenes.
This
is
how
stuff
is
already
working.
It
already
operates
off
of
kind
of
the
current
context.
D
E
There's
an
necessary
just
interjecting
that
we
we
have
some
kafka
instrumentation.
That
is
explicitly
creating
spans.
E
Without
affecting
the
context,
so
I'd
have
to
look
at
it.
Look
at
that
in
more
detail,
but
I
believe
we
have
some
use
cases
where
we
definitely
want
to
be
creating
spans
with
parents
without
using
the
context
in
any
way
or
affecting
the
context
in
any
way,
it'd
be
interesting
to
see
how
to
actually
encode
those
here
and
does
it
end
up
really
clunky.
Do
we
end
up
creating
extra
objects
that
maybe
we
don't
need.
D
Yeah
that
would
be
interesting
to
know
about
so
right
now.
This
is
open.
I
kind
of
I
started
a
prototype
for
this.
I
have
one
thing
remaining
to
do
on
it.
D
It's
it's
open
as
a
draft
pr
right
now,
but
I
think
the
discussion
at
the
meeting
was:
are
there
enough
prototypes
and
should
we
just
make
this
a
requirement
now,
and
I
think
people
were
pretty
much
behind
that,
so
I
think
this
is
very
likely
to
happen
if
it
hasn't
already
in
terms
of
having
spans
and
not
necessarily
affecting
the
current
context.
D
This
is
a
reality
like
this
is
a
thing
like
you
still,
you
can
create
spans
that
aren't
attached
to
a
contacts,
so
this
is
still
a
thing
that
you
can
do
the
problem.
Is
those
fans
end
up
having
to
be
like
leaf
nodes?
I
guess
if
you,
if
you
want
them
to
be
somewhere
further
up
in
the
trace
like
you,
do
need
them
in
a
context
of
some
kind
to
be
able
to
express
that
parent
relationship.
D
It's
up
to
you
what
context
you
stick,
those
in
so
you
could
like.
If,
if
it
made
sense,
they
could
go
into
like
an
empty
context
and
wouldn't
you
know
necessarily
become
part
of
your
trace
or
they
yeah.
You
stick
them
in
an
empty
context.
E
I
guess
the
question
there
is
whether
we
end
up
having
a
lot
of
ceremony
around
wrapping
things
like
creating
a
span
wrapping
it
in
a
context.
So
you
can
pass
it
as
a
parent
to
another
span
that
you're
creating
and
does
it
get
kind
of
wordy
and
clunky
and
hard
to
use.
D
Yeah,
so
this
is
kind
of
one
of
the
things
that
that
has
become
apparent
to
me
in
the
post.
Oh
top
66
world
is
that
I
feel
like
our
apis
have
become
a
little
clunky
in
this
area
in
general
already
just
because
you
kind
of
have,
I
don't
know
if
you're
using
the
start
span
api.
I
guess
which,
like
I
keep
trying
to
talk
myself
down
from
hating
this
too
much
because
start
span
does
seem
to
be
used
much
less
than
other
things.
It
seems
to
be.
D
You
want
a
context,
because
you
want
to
go
ahead
and
use
this
thing
and
either
activate
it
as
the
current
thing
somewhere
or
use
it
as
a
parent
somewhere.
So
I
I
don't
know
what
I
would
call
this.
D
I
would
call
this
span
context
duality
or
something
as
like
the
name
of
the
problem,
but
it's
just
like
it's
it's
unfortunate
and
there
were
some
radical
proposals
which
initially
I
thought
were
like
completely
crazy,
when
I
saw
them
that
I've
come
around
to
thinking,
are
entirely
correct
and
are
probably
really
good
ideas
and
one
of
them
was
just
like
remove
span
from
the
the
api
all
together.
D
I
think
that
showed
up
like
last
november-
and
I
was
like
this
is
this-
is
ridiculous,
but
then,
after
we
made
these
context
changes,
it
makes
a
lot
of
sense.
You
just
kind
of
everything
would
operate
on
a
context
instead
of
a
span,
and
I
think
I
think
that
would
solve
a
lot
of
problems,
but
I
think
it's
a
little.
D
I
think
in
general
people
think
it's
a
little
late
in
the
game
for
such
a
sweeping
change,
but
you
would
still
kind
of
have
you
know
so.
The
way
that
would
work
is
that
everything
would
actually
end
up
going
through
tracer.
You
would
still
kind
of
have
like
tracer
start
span.
It
would
return
a
contacts,
but
then
you
would
have
like
if
you
wanted
to
set
an
attribute
on
the
current
span.
It
would
be
like
you
know.
D
E
So
on
that,
I
might
sorry
I
might
try
to
port
out
kafka
instrumentation
that
we
have
right
now,
it's
kind
of
in
flux,
because
the
team
that's
been
building.
It
has
been
kind
of
going
back
and
forth
on
what
they
actually
want,
but
I
might
try
porting
what
they
have
over
to
the
open
telemetry
api,
with
your
context,
only
parenting
just
to
see
how
terrible
that's
going
to
look.
D
Yeah,
I
think
that
would
be
a
great
experiment
and
probably
give
us
some
valuable
feedback
yeah
so
to
work
around
these
things.
This
is
kind
of
what
I
came
up
with
and
I'm
I'm
actually
somewhat
happy
with
the
apis
that
we
have,
I
feel
like
they.
D
There
is
a
little
bit
of
ceremonial
and
a
little
bit
of
clunk,
but
it's
kind
of
minimized.
The
two
things
that
we
have
are
since
tracer
start
span
returns
a
span.
I
feel,
like
you
know,
50
of
the
time
you
want
that
span.
50
of
the
time
you
want
to
span
in
a
context,
so
for
the
times
that
you
want
to
span
you,
the
return
value
is
what
you
want
and
for
the
times
where
you
actually
wanted
it
in
a
context.
D
There's
this
context
with
span
method
and
you
just
pass
it
a
span
and
it
will
return
you
a
context
with
that
span
as
the
current
span
and
it
will
default
to
the
current
context.
D
You
can
override
that
by
passing
in
a
a
context
that
you
would
like
it
like
this
to
be
the
span
to
be
injected
into.
I
guess
and
then
the
other
thing
is
sometimes
you'll
have
a
context
and
you
want
to
get
at
the
current
span
and
for
that
we
still
have
tracer
current
span
by
default.
It
just
uses
the
current
contacts,
but
you
can
pass
in
an
arbitrary
context
and
it
will
pull
off
the
current
span
if
it
exists.
D
D
Yeah
I
feel
like
this
is
not
too
bad,
but
I
think
definitely
looking
for
feedback
and,
if
there's
any
ideas
for
things
that
are
better.
D
Yeah,
the
last
thing
I
need
to
add
is:
is
this
just
kind
of
pass
through
the
parent
context
to
onstart
it's
not
very
hard
to
do?
Maybe
if
I
get
some
time
this
afternoon,
I
can.
I
can
do
that
and
if
that-
and
I
think
people
are
gonna-
go-
go
forward
with
this.
So
when
those
two
things
align,
if
we're
happy
with
the
work
over
here,
we
can
get
that
on
to
master
at
some
point.
B
It
seems
yeah
well,
some
of
it
went
over
my
head
to
be
honest,
but
it
seems
seems
fine,
I'm.
I
guess
I'm
curious
to
see
what
some
instrumentation
looks
like
with.
D
B
But
yeah,
some
of
the
that's
really
where
like
pulling
the
like,
removing
the
ability
to
create
a
span
entirely,
I
feel
like
would
end
up
with
whatever
that
crazy
proposal
was
like.
I
feel
like
it
a
lot
of
times
in
tests.
It's
just
like
yeah,
let's
make
a
bunch
of
spans
in
an
array
and,
like
you
know,
roll
them
by
hand,
so
that
would
be
the.
B
D
E
One
of
the
things
yeah
just
because
I've
been
mucking
about
in
some
of
this
code
recently,
one
of
the
things
that
we
do
a
lot
in
tests
is
create
a
span
data,
at
least
in
the
exporter
test.
We
create
span
data
and
we
don't
really
preserve
the
invariants.
That
span
gives
us
so
the
span
data
is
not
expected
to
be
a
public
api
or
it
is
not
a
public
api,
but
it
is
kind
of
available
to
exporters
but
really
supposed
to
be
treated
as
a
read.
E
Only
like
you
receive
a
span
data
you
don't
create
as
band
data
and
a
bunch
of
our
tests
create
span
datas
that
have
data
that
you
wouldn't
see
on
nils,
for
example,
that
you
wouldn't
see
in
span
data
that
was
created
from
a
span.
E
So
I
wonder
if
that's
like
an
area
that
we
should
clean
up
and
then
some
of
these
changes
will
be
less
significant.
Perhaps.
B
Yeah,
I
think
I
remember
it's
like
we
have
there's
like
six
different
functions
for
like
generating
span
data's
for
each
export.
It's
like
maybe
just
make
one
nice
one
instead
of
like.
Oh
it's
a
no
resource,
but
in
reality
that
would
never
happen
so
yeah.
I
agree.
D
Yeah
also
agree
there
and
I
think
one
one
of
the
things
that
we're
kind
of
lacking-
and
I
don't
know
I
feel
like
there's-
probably
an
issue
around
this-
is
like
because
because
all
these
are
individual
packages,
we
don't
have
a
lot
of
great
places
to
put
shared
stuff
unless
it's
in
the
api,
which
is
probably
not
a
great
place.
To
put
it
so.
E
Yeah,
it's
not
clear,
like
we
have
the
http
to
status
thing,
that's
in
the
api
right
now,
in
kind
of
a
utils
thing
that
is
then
mixed
into
status,
and
it's
just
kind
of
a
weird
place
to
do
things,
and
certainly
in
shopify
we're
finding
there's
a
bunch
of
instrumentations
that
want
shared
utilities
and
we
just
kind
of
dump
that
stuff
on
the
tracer
right.
Everything
just
ends
up
in
this
module.
That
is
a
dumping
ground
for
everything,
so
yeah,
I
think,
having
a
structured
place
for
this
is
useful.
E
I
think
it
belongs
in
the
api
rather
than
the
sdk,
because
a
lot
of
it
is
going
to
be
useful
for
instrumentation.
That
is
not
our
auto
instrumentation
right.
Our
auto
instrumentation
packages
implicitly
depend
on
the
sdk,
but
we're
expecting
that
there's
going
to
be
instrumentation
integrated
into
things
like
you
know,
redis,
libraries
or
whatever,
and
those
should
only
depend
on
the
api.
E
So
from
that
perspective,
api
seems
like
a
better
place
for
it,
but
then
the
flip
side
of
that
is
like
these
are
just
things
that
are
composing
building
blocks
from
the
api.
So
like
should
we
have
a
utils
gym,
or
should
we
have
a
clear
place
in
the
api
where,
like
these
are
utilities,
you
can
mix
them
in
or
whatever.
D
D
Place
for
those
things
and
keep
the
api
just
focused
on
on
api
because,
like
at
least
you're
giving
end
users
still
like
the
option
to
pull
in
the
utils
as
long
as
the
utils
are
completely
optional,
it's
like
you're,
yeah
you're,
giving
kind
of
the
end
user
at
least
the
option
to
pull
these
things
in
not
forcing
upon
them.
E
Offense,
so
I
just
think
there
needs
to
be
a
place
that
we
can
stick
all
this
stuff
that
is
easily
reachable
and
only
depends
on
the
api.
It
shouldn't
pull
in
the
sdk
or
pull
in
really
any
other
dependencies.
It
should
just
be,
I
think,
fairly
straightforward
transformational
functions.
D
Yeah,
I
think
I
think
that
makes
sense,
I'm
kind
of
a
fan
of
maybe
making
it
a
separate
package,
and
I
think
that
would
that
would
very
likely
knowing
what
I
know
about
the
other
open
telemetry
projects,
the
other
language.
D
D
Yeah
tbd
but
yeah,
I
think
so.
I
think
there
is
this
set
of
shared,
like
shared
utilities,
that
you're
going
to
want
to
use
in
instrumentation
that
we
could
use
or
that
first
party
developers
could
use
without
wanting
to
pull
in
anything
other
than
api
and
the
utils,
and
then
there's
probably
a
set
of
like
common
testing
utilities.
E
D
That's
kind
of
what
I
was
thinking.
I
know
I
know
there's
rack
test
and
that
was
kind
of
the
thing
that
went
through
through
my
mind
as
that's
something
we
could
model
over
after,
but
yeah
so
tldr.
I
think
we
have
two
missing
packages.
I
guess
one
of
them
is
a
common
utils
package
to
be
used
by
instrumentation
authors.
That
only
depends
on
the
api
and
the
other
is
like
a
set
of
shared
kind
of
like
testing
utils.
E
We
should
probably
create
at
least
the
common
package
pretty
soon,
because
I
feel
like
we're
going
to
have
an
increasing
number
of
things
that
we
want
to
stick
in
there
and
there's
probably
already
existing
thing,
but
there's
definitely
existing
things
that
we
can
extract
from
instrumentation
like
the
dolly
stuff
for
handling,
utf-8
and
truncation
and
so
forth.
D
E
Right
yeah,
I
had
an
open
issue
for
semantic
convention
helpers.
Do
you
feel
that
also
belongs
in
the
common
pack?
I
guess
it
probably
does
yeah.
E
What
yeah,
I
don't
know,
I
mean
they're
they're,
strictly
helpers
that
are
built
using
the
api
that
aren't
full
semantic
conventions.
E
D
So
the
next
thing
that
we
talked
about
was
the
baggage
header
name
right
now,
we're
using
we
in
ruby
are
using
baggage,
which
is
the
proposed
name
of
the
w3c
header,
the
specs
still
this
is
this-
has
changed
a
lot.
D
Basically,
baggage
used
to
be
called
correlation
context,
both
through
the
w3c
and.
D
For
open
telemetry,
I
feel
like
I
am
halfway
responsible
for
all
of
this,
because
the
correlation
context,
header
tragically,
had
a
dash
separating
correlation
and
context
in
it,
and
it's
it's
a
can
of
worms.
The
w3c
also
has
trace
contacts,
and
it
has
two
headers
trace
parent
and
trace
state
and
there's
like
this
long
rationale
of
why
they
left
the
dash
off
and
why
they
canonicalize
them
as
being
like
all
lower
case.
D
So
as
long
as
you
get
the
header
approximately
right
things,
your
http
libraries
will
should
normalize
things
and
everything
should
work
out.
But
whenever
you're
trying
to
send
contacts
or
something
a
little
bit,
more
exotic
rules
get
weird
and.
D
D
So
yeah
removing
that
dash
turned
out
to
be
spawned
a
mini
month-long
bike
shed
where.
D
D
This
issue
is
still
just
kind
of
trying
to
figure
out
if
we
should
use
a
an
hotel,
specific
version
of
this
header,
and
the
reason
is
that
the
w3c
distributed
tracing
working
group
kind
of
has
a
draft
spec
for
baggage.
It's
it's
an
editor's
draft
format,
which
is
like
a
very
early
version,
it's
kind
of
like
an
alpha.
I
guess
you
could
think
about
it
as
an
alpha
version
of
the
header
and
should
open
telemetry
rely
on
this
alpha
version
of
the
header.
D
Is
it
going
to
be
complicated
for
the
distributed
tracing
working
group?
Is
it
going
to
lock
them
into
not
being
able
to
change
things
later?
D
Tldr
there's
a
meeting
later
today
of
that
group,
and
we
will
discuss
this,
but
we're
going
to
choose
one
one
or
the
other,
either
hotel
baggage,
which
would
kind
of
adhere
to
like
this
editor's
draft
version
of
the
baggage,
spec,
but
kind
of
leave
the
distributed
tracing
working
group
to
you
know
freely,
make
changes
and
not
have
to
worry
about
the
consequences,
or
is
it
stable
enough
where
we
can
just
use
the
the
actual
header
name
so.
D
This
is
important
because
yeah,
nobody
is
using
the
proper
nobody's
using
the
same
header
names.
Your
correlations
are
probably
not
propagating
really
well
and
open
telemetry
right
now,.
D
This
next
one,
I
will
keep
it
short
metrics
and
logs
protos,
have
s
added
to
the
end
and
trace
does
not
so
there's
an
issue
about,
should
we
add
the
s
and
it
turns
out
to
be
a
huge
can
of
worms
as
well,
like
it
grpc
kind
of
has
conventions
based
around
this
and
they
all
break
down
and.
D
Yeah,
I
always
just
have
to
like
chuckle
every
time
I
see
this
like
and
wonder
like
how
how
much
like
how
much
engineering
dollars
has
gone
on
to
like
whether
or
not
something
should
end
in
an
s
I
feel
like
this
is
always
like
a
really
big
deal
in
the
rails
world.
It's
like
very
important
that
you
have
the
s,
but
only
that
you
have
it
in
the
right
places
and
very
important
that
you
don't
in
others
in
other
places.
So
so
s
is
a
very
expensive
letter.
I
think.
D
All
right,
that's
the
end
of
the
spec
meeting.
D
I
will
aim
to
do
this
in
half
the
time
in
the
future,
but
I
think
yeah.
I
think
we
didn't
talk
about
the
spec
the
whole
time.
We
did
kind
of
at
least
touch
on
some
things
that
are
relevant
to
to
open,
telemetry,
ruby
and
kind
of
some
things
that
we
need
around
these
these
common
packages
and
just
this
whole
I
don't
know
the
discussion
about
context
for
spam
for
spam
contacts.
I
think,
is
kind
of
important
a
to
know.
D
I
know
last
time
we
were
talking
about
our
our
next
milestone.
It
looks
like
francis
has
done
some
work
here.
This
is
true.
E
E
Yeah
and
then
there's
a
a
few
instrumentation
things
that
we've
brought
along.
You
know
we
we
often
do
a
couple
of
these
and
then
pump
the
rest
to
the
next
milestone,
but
these
seem
like
interesting
ones.
D
Cool
yeah
now
this
this
looks
good
and
I
think
it
is
good
to
have
this
a
good
first
issue
and
help
on
tags
on
things.
It
seems
like
there
are
some
aws
interns
around
and
they
seem
to
go
slurping
up
these
issues.
So
if
there's
anything
that
would
be
good
for
for
them
label
it
as
such
and
it
might
magically
get
done.
A
D
Yeah,
I
believe
we
do
have
an
issue
for
this
yeah.
There
is
one
it
seems
likely
that
aws
interns
would
be
a
a
candidate
for
these.
D
B
Are
there
any?
Are
there
any
other
adapters
that
we
think.
B
Could
per
you
know,
have
a
har,
sorry,
a
high
roi
that
we
want
to
target,
or
I
think
these
are
probably
fine
given
a
recent
pace,
but.
E
C
A
The
way
it's
written
up
so
it
may
not
be
perfect,
but
that
would
at
least
get
some
rail
specific
stuff
in
there.
And
then
I
don't
know
what
the
return
on
investment
would
be.
But
personally
I
would
love
to
see
the
db
one
get
done,
because
it's
the
the
one
and
only
one
I
need
that's
not
done
at
the
moment.
B
A
B
Yeah,
it
can't
hurt
I'd
like
to,
in
addition
to
graphq
I'll,
be
able
to
grab
one
more
by
this
for
this
milestone.
So
how
about
right
here,
one
more
that's
number
one!
I
I.
A
A
B
Makes
sense
yeah,
I
know
something
large
sorry.
E
You
go
ahead,
so
it's
just
gonna
say
we.
We
have
a
rack
instrumentation
gem.
I
just
don't
think
it's
written
to
be
extensible,
so
it's
not
written
to
be
to
have
something
like
the
rails
gym
plugged
in
on
top
of
it.
So
if
you
were
going
to
use
it
you'd
end
up
having
like
two
middlewares,
for
example:
you'd
have
like
the
rack,
middleware
and
then
the
rails
instrumentation.
B
Interesting
yeah,
it's
the
way
we've
ended
up
approaching
it
with
datadog
is
there's
some
sort
of
black
magic
going
on
where
we're
attaching
a
bunch
of
context
onto
the
rack
environment
and
we
sort
of
wait
until
we're
in
rails
or
sinatra
to
say
just
and
then
we
sort
of
push
back
up
some
enhanced
metadata
onto
the
the
rack
level
spans.
B
If
it's
like,
oh
well,
now
we
have
some
well,
I'm
not
doing
a
good
job
here,
but
I
don't
know
some
some
information
about
the
route,
for
example,
or
something
like
that,
so
I
don't
know
where
I
was
going
with
that
I
was
just
talking
anyway
yeah.
I
think
it's
not.
I
don't
know
I
I
I'll
stop
talking
now.
I'm
not
sure.
E
Yeah,
it's
basically,
you
have
some
additional
context
that
propagates
in
some
way-
and
you
know
the
end-
is
the
obvious
place
to
do
that.
So
you
just
stick
some
information
in
there
and
then
in
your
rack,
middleware,
when
you're
finishing
the
span,
you
pick
up
any
additional
attributes
from
there
and
and
stick
them
into
the
span,
something
like
that
right,
yeah,
the
problem
yeah.
The
problem
right
now
is
the
rack.
E
Instrumentation
is
not
written
to
be
extensible,
and
it
really
should
be
because
you
don't
really
want
to
have
like
a
like.
You
typically
either
have
a
effectively
a
naked
rack
application
where
you
want
to
use
rack
instrumentation
or
you
have
a
rails
application
or
a
sinatra
application
or
hanami
application
right,
and
you
want
you'd,
ideally
like
to
reuse
some
of
this
common
rack
functionality
in
those
instrumentations.
But
you
don't
want,
like
rackspan,
plus
yeah,
yeah,
braille
spam.
B
Yeah,
I
think
right,
okay,
so
then,
and
the
way
we
get
around
that
within
datadog
is
we.
We
basically
just
turn
the
rackspin
into
a
duplicate
of
whatever
the
lower
level
thing
is
because
yeah,
I
don't
know,
for
whatever
reason,
we've
chosen
that
but
yeah,
I
think,
starting
from
scratch.
Maybe
if
we
just
have
like
a
hook
or
something
within
the
rack
thing
or
we,
we
have
a
canonical
something
on
the
on
the
rack
environment
that
can
be
looked
up
from
within
the
other
ones.
Something
like
that
we
could.
D
Agree
yeah,
I
mean
I'm
I'm
open
to
some
proposals
here.
I
think,
like
generally
like
the
rackspan
is
kind
of
the
closest
to
the
request.
So
it
is
kind
of
it
is
something
that
you
want
to
capture
and
then
you
have
ultimately
your
sinatra
or
your
rail
span
that
sits.
Probably
you
know,
20
middleware,
deep
or
something.
D
In
reality,
yeah,
you
do
kind
of
want
to
know.
You
know
you
want
to
treat
those
as
separate
operations,
but
probably
if
you
want
to
decorate
some
stuff,
you
know
back
up
to
the
rackspan,
especially
stuff
about
after
routing
has
happened.
For
example,
perhaps.
E
So
yeah
from
what
I've
seen,
I
don't
think
it's
generally
super
useful
to
have
both
spans
there.
I
think
it's
generally
useful
to
have
one
span
representing
the
request
where
you're
measuring
its
start
time
and
duration
as
early
as
possible,
but
where
you've
updated
some
state
for
the
span
as
you've
gathered
it
in
high
level
frameworks.
B
E
D
E
Yeah,
it
would
also
be
useful
sorry,
I
just
can
say
it's
also
useful
if
people
can
go
through
some
of
the
other
existing
issues
here
that
aren't
in
this
milestone
and
if
there's
anything
that
you
really
want
or
you
think
it's
more
urgent,
we
should
get
done
sooner
then
tag
them
for
this
milestone.
D
D
D
So
I
know
rails
has
some
hooks
for
you
to
actually
get
at
the
middleware
chain,
at
least
as
the
middleware
chain
as
rails
is
aware
of
it
and
kind
of
like
stick
this
thing
on
the
as
as
the
first
thing
that
we'll
process
sinatra,
I
forget,
if
there's
anything
or
if
we're
even
using
anything,
but
I
I
feel
like
as
you
as
you
get
away
from
rails,
it
gets
a
little
bit
harder
to
do
this.
You
can
do
unholy
things
by
monkey,
patching
rack
itself
or
rack
builder.
C
That
that's
that's
good,
yeah,
I'd,
almost
even
push
back
against
trying
to
magically
do
it
for
rack.
I
think
for
the
frameworks
that
build
on
it
having
it
being
auto
magic
is
amazing,
but
I
think
for
rack
like
just
like
the
way
I've
seen
used
at
shopify,
like
the
teams
that
are
using
it
are
explicitly
using
it
because
of
the
manual
aspect
of
it
where
it
does
only
exactly
what
they
tell
them.
So
I
think
like
them
having
to
manually,
add
the
middleware
for
instrumentation.
D
B
I
I
guess
I
had
put
in
a
graphql
pr,
francis
had
given
great
feedback
already,
which
I
think
is
all
pretty
reasonable,
and
I
want
to
implement
it.
But
I
am
curious
matt
if
you
happen
to
have
written
a
graphql
instrumentation
in
your
in
any
past
lives.
There's
some
like
there's.
Basically,
this
sort
of
like
it's
actually
kind
of
interesting,
and
one
of
these
things
like
it's
worth
thinking
about
in
general,
where
it's
like
do
datadog
has
some
whatever
it
was
like
written
in
2018
and
you
basically
have
to
manually
or
17.
B
B
I
am
not
a
graphql
user,
so
it's
unclear
whether
doing
that
would
sort
of
blow
up
people's
instrument.
You
know
applications
by
creating
a
gazillion
spans
and
if
that's
something
or
whether
that's
the
right
way
to
do
things-
and
you
know
man,
the
manual
pain,
isn't
where
it
doesn't
really
provide.
Any
benefit
so
I'm
kind
of
curious
from
other
vendor
perspectives.
D
Yeah,
no,
I
I
don't
have
a
lot
to
add.
I
think
that
just
looking
through
this,
it
looks
like
francis
and
shopify
has
some
experience
with
this.
D
B
Yeah
we've
seen
I
I'm.
The
only
reason
I'm
concerned
is,
I
feel,
like
there
was
some
it's
a
particularly
noisy
instrumentation
in
terms
of
it's
good.
It
gives
lots
of
granularity,
but
sometimes
it's
like
do
you
need
every
single
resolver
to
be
a
span?
And
you
and
you
know,
do
you
need
every
single
schema
to
be
better,
and
I
think
the
answer
is
yes,
but
maybe
also
from
so
my
like
sort
of
next
step
was
like,
maybe
also
have
config
like
right
now.
B
This
has
which
configuration
hook
like
an
option
for
configuration,
configuration
option
so
maybe
use
that
in
case
users,
I
guess
want
less
there
if
they're
getting
charged
per
span
or
they
don't
have
the
they
don't
want
the
memory
overhead
or
something
they
can
scale
back
things
a
little,
that's
sort
of
a
new
paradigm
that
we
don't
really
do
a
lot
of
within
ruby.
Yet.
D
Yeah
come
to
think
about.
You
know.
I
have
seen
some
graphql
traces
coming
from
ruby
and
I
think
it
might
have
been
based
off
of
dd
trays
and
there
were
a
lot
of
fans
and
there
were
a
lot
of
very
short
spans
and
a
lot
of
them
kind
of
were
coming
out
of
the
leafs,
so
I
could
see
having
some
knobs
around
that
being
being
useful
if
it's
too
chatty,
but
at
the
same
time
I
think
I
think
it's
okay.
D
If
the
graphql
instrumentation
isn't
perfect
out
of
the
box
yeah,
you
know
as
long
as
it's
as
long
as
we
like
what
it
does.
I
think
we
can
always
add
more
functionality
in
to
kind
of
like
to
improve
it
a
little
bit
later.
So
like
yeah
all
right.
I
would
definitely
take
that
approach
like
if
you
think
that
instrumenting
this
base
schema
class
is
like
the
best
option,
with
the
drawback
that
you
get
a
few
too
many
spans.
E
Yeah,
probably
an
allow
list
in
a
deny
list
for
for
schemas
would
be
a
useful
way
of
dealing
with
this,
because
if
you
just
start
with
the
default
of
instrumenting
everything,
and
then
if
people
find
that
certain
things
are
particularly
noisy,
then
they
can
just
add
them
to
a
deny
list
that
that's
probably
the
most
convenient
and
then
separately
support
an
allow
list.
If
people
just
want
to
trace
specific
things,.
B
B
D
Well,
thanks:
everyone
see
you
already
online
and
see
you
next
week,
thanks
bye,.