►
From YouTube: 2021-10-05 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
C
Mac,
could
you
summarize
for
me
in
like
a
minute
what
this
whole
like?
Are
you
familiar
with
the
otlp
arrow
stuff?
That's
ongoing
with,
like,
like
there's
like
a
proposal
for
otlp
columnar
encoding
support
that
appears
related
to
one
schema
url.
I
was
trying
to
look
into
schema
url
stuff,
but
it
looks
like
josh
and
some
folks
from
josh
from
your
organization,
some
folks
from
f5
have
this
larger
upstream
otep
about
basically
making.
C
C
And
it's
incredibly,
like
you
know
the
like.
My
my
eyes
are
bleeding
trying
to
like
digest
it,
but
it
seems
like
lightstep,
has
some
sort
of
interest
in
it.
So
I
was
wondering
if
you're
familiar
with
it
or
like,
what's
the
general
overall
thing,
but
if
not,
I
don't
want
to
put
you
on
the
spot.
D
You're
putting
me
on
the
spot,
but
yeah
like
so
I
don't
know
that
I
can
add
a
lot
of
color
to
it
other
than
I
can
read
through
this
and
talk
to
josh
a
little
bit
and
try
to
get
a
get
some
sort
of
reasonable
summary
together
for
next
week.
Perhaps.
C
It
would
be
good
to
know
justin,
it
seems
like
it
has
lots
of
benefits
and
has
also
lots
of
impact
on
like
yeah.
I
don't
know
otlp
in
general,
so
it's
I'm
just
kind
of
trying
to
scope
out
whether
this
is
like
some
random
guy
from
f5
being
like
ooh.
This
is
a
good
idea
and
by
the
way,
I'm
one
person
with
10
of
my
time
working
on
it
or
if
it's
like
there
was
some
sort
of
conversation
and
agreement
between
organizations
being
like.
C
B
C
Next
week
or
whatever,
or
if
you
see,
if
you
have
an
easier
way
to
summarize
it
that
isn't
5000,
you
know
words
of
text,
it
would
be.
I
certainly
got
a
little
lost,
so
any
help
is
appreciated.
D
Cool
yeah
I'll
try
to
get
some
some
background
knowledge
on
that
it
does
look
interesting
at
a
glance.
It
just
looks
like
it's
some
way
to
kind
of
make
the
protocol
as
compact
as
possible.
Without
you
know,.
D
Cool,
so
I
think
most
people
are
here.
C
Oh,
oh
before
you
get
started
also,
I've
been
speaking
a
little
bit
with
amy
toby,
who
I
think's
made
some
contributions
here.
She's
the
author
of
like
hotel,
cli,
which
I
know
andrew
haywith,
has
contributed
on
and
I
think
she's
interested
in
joining
the
sig
more
frequently,
but
has
bad
timing
things,
but
I
told
her
to
come.
Come
hang
out
sometime
and
see
if
there's
any
issues,
but
so,
if
you
guys
know,
I,
you
know
see
anything
low
hanging
going
forward.
We
might
have
some
other
folks
interested
in
contributing
soon.
C
So
that
could
be
good.
Sorry
as
and
anyway,
that's
all
I
got
cool
yeah.
D
All
right
so
there's
an
otlp
d011
release
candidate.
It
would
have
the
exponential
histogram,
but
I
think
yeah.
I
think
one
of
the
big
blockers
to
this
is
optionals,
which
we
talked
about
last
week.
D
D
So
probability,
sampling
they're,
I
guess
the
others
were
merged,
but
now
kind
of
the
blocker
is
that
they're
they
were
kind
of
two
proposals
in
how
to
propagate
information
between
services.
One
was
using
w3c
trace
state.
It's
the
thing
that's
available
to
us
today
to
use,
but
there
is,
there
has
been
some
discussion
at
the
w3c
distributed
tracing
working
group
about
modifying
the
trace
parent
to
be
able
to
pass
a
sampling
probability
there.
D
So
I
think,
given
that
the
w3c
hasn't
completely
said
no
go
away
with
this
proposal.
I
think
there
is
some
interest
in
trying
to
see
if,
if
they
would
be
interested
in
adopting
this.
D
D
Yeah
it
does
not
directly
compete
with,
but
is
overlapping
with
467.,
so
are
kind
of
the
the
two
open
issues
there.
So
I
don't
know
it's
it's
encouraging
that
the
w3c
hasn't
completely
said
no
to
this
stuff,
but
I
wouldn't
hold
my
breath
on
it
actually
getting
passed
through
anytime
soon,
but
it
certainly
would
be
nice.
It
would
be
much
easier
to
do
this
in
transparent
rather
than
trace
stage.
D
The
schema
file
things
that
we're
calling
attributes
now,
both
on
metrics
and
spans.
I
think
we're
called
labels.
D
So
tiger
is
just
asking
the
otef
says
labels.
Do
we
have
to
stick
to
labels
or
can
we
rename
to
attributes?
I
think
the
discussion
was
the
otaps
aren't
kind
of
written
in
stone,
it's
kind
of
like
once
you
actually
get
it
to
the
spec
repo.
That's
when
the
decision
really
needs
to
be
final,
so
it
would
be
okay
to
make
that
change.
D
D
I
don't
know
why,
but
they
were
talking
like
I
feel
like
this
stuff
is
fine
having
this
as
just
a
flattened,
dotted
key
with
a
value,
but
the
discussion
went
towards
like
creating
a
file
type
that
is
itself
like
a
structure,
structured
data.
D
I
think,
ultimately,
it
would
end
up
just
having
to
flatten
the
stuff
again.
I
think
we
had
this
discussion.
We
had
similar
discussions
when,
like
otlp
technically
allows
you
to
have
values
that
are
that
are
maps
where
the
values
themselves
can
be
maps
and
right
now,
like
the
only
thing
that
is
kind
of
preventing
that
from
getting
out
of
control
is
like
the
tracing.
Spec
is
like
just
don't
use
this,
but
I
feel
like
yeah.
D
D
Another
thing
that
we
spent
some
time
on
was
talking
about
retries
for
otlp.
Essentially,
the
conversation
was
there's
not
enough.
The
specs
are
not
saying
enough
about
retries
for
anybody
to
really
implement
them.
D
Apparently,
there's
grpc
retry,
which
I
think
is
pretty
straightforward,
and
there
was
not
a
lot
of
disagreement
about
using
that,
but
this
discussion
basically
exploded
into.
We
probably
need
a
retry
sing
to
hash
everything
out,
because
I
think
they
were
discussions
were
like
you
know,
for
requests
that
are
successful.
That's
pretty
straightforward
for
requests
that
fail.
That's
pretty
straightforward,
but
there's
like
this
whole
gray
area
where,
like
you,
can
have
partially
successful
requests
and
that's
where
things
fall
apart.
D
So
I
don't
know
jack
was
trying
to
be
yeah,
probably
sidebar
conversations
equal
new
sig
but
yeah.
I
think
jack
was
trying
to
at
least
be
pragmatic
and
be
like
right.
Maybe
we
can
spec
the
things
that
we
know
about
and
then
the
success,
the
you
know,
successful
requests
and
the
failed
requests,
and
then
we
can
leave
the
gray
area
gray
and
just
mention
that
it's
unspecified
at
this
time.
D
So
I
think
they
are
trying
to
make
some
some
kind
of
a
progress
here,
but
I
suppose
whatever
they
do,
we
probably
need
to
keep
an
eye
on
this,
just
to
make
sure
that
our
exporters
are
doing
the
right
thing
since
we're
we're
not
grpc
based.
D
D
This
is
ultimately
about
the
sdks
and
apis.
What
happens
especially
like
in
a
dynamic
language
when
you
pass
garbage
parameters
in
and.
D
I
think
kind
of
the
core
principle
that
tigran
was
laying
out-
which
I
agree
with
in
principle,
is
that
if
you're
using
the
no
op
api
and
you
hand
some
data
to
it
and
then,
if
you
hand
that
same
data
to
something
backed
by
an
sdk
like
you
should
not
get
an
exception,
there's
no
exception
for
the
api.
There
should
be
no
exception
from
from
the
sdk.
D
I
think
the
devil
is
in
the
details
and
there
are
just
a
lot
of
ways
that
you
can
mess
this
up
in
a
dynamic
language,
so
the
conversation
went
all
over
the
place.
Somebody
was
talking
about
a
street
mode.
It's
just,
I
don't
know
like
everything.
D
Everything
that
we've
kind
of
talked
about
in
the
past
has
resurfaced.
In
this
conversation
I
don't
know
it
was.
D
D
The
thing
that
definitely
exists
is
there's
a
survey,
so
perhaps
there's
a
certain
way
to
figure
out
how
this
actually
works
already.
But
if
we
want
to
fill
this
out,
we
should
just
add
ruby
and
just
kind
of
document
what
we
do
and
I
think,
by
documenting
what
different
languages
do
that
will
help
influence
the
outcome
of
all
this.
D
D
I
guess
it's
hard
to
ensure
that
whatever
you
pass
to
the
noaa
implementation
is
going
to
work
when
you
plug
in
an
sdk
without
adding
like
a
bunch
of
runtime
checks
into
the
no
op
implementation,
and
it
just
seems,
and
that
in
general
are
is
there,
are
performance,
concerns
those
kind
of
end
up
being
those
end
up
being
a
waste
of
resources
over
time
and
there's
no
way
to
kind
of
reclaim
it.
I
guess
it's
like.
D
Ideally,
you
would
want
some
kind
of
static
analysis
to
figure
this
stuff
out
and
I
think
that's
one
of
the
things
that
we
kind
of
like
hand
waved
when
we
were
talking
about
this.
Like
maybe
some
days,
blah
blah
blah,
sorbet
or
ruby
will
provide
something,
and
we
will.
We
will
adopt
that,
but
yeah,
I'm
rambling.
But
then
you
know
there
was
kind
of
the
the
discussion
of
like
well.
D
D
D
Yeah,
I
guess,
should
we
fill
this
out?
Does
anybody
want
to
volunteer
to
fill
this
thing
out
just
so
that
we
can
have
some
kind
of
input
as
to
what
so,
what
we're
currently
doing
and
if
we
think
what
we're
currently
doing
is
a
good
approach
or
not.
E
For
runtime
stuff,
we're
generally
for
for
the
most
part,
I
think
we're
checking
and
then
inserting
a
default.
In
some
cases
we
may
call
the
error
handler.
We
never
just
raise
f
right.
C
C
C
I've
been
I've
been
taught.
The
only
reason
I'm
volunteering
is
I've,
been
touching
a
bunch
of
the
conflict
stuff
anyway.
So
it's
kind
of
top
of
mind.
Where
is
ruby
on
here?
Oh,
I
guess
we
would
have
to
put
it
in.
D
But
I
think
in
these
situations,
where
whatever
you
passed
and
did
result
in
an
error
condition,
we
do
try
to
just
pipe
that
through
the
error
handler.
Is
that.
E
D
Yeah,
I'm
I'm
hand
waving
there,
but
I
feel
like
that
was
kind
of
like
our
general
approach
was
to
like
try
not
to
fail.
If
you
can
do
something
sensible,
but
in
the
event
that
none
of
that
works
out,
try
not
to
raise
yeah.
E
Like
the
api
is
very
thin
and
doesn't
do
much
at
all,
so
any
error
handling
is
deferred
to
the
sdk,
so
the
sdk
implementation
of
spam,
for
example,.
C
Sure
should
we
make
an
issue
and
you
can
assign
it
to
me
yeah.
Where
should
we.
D
D
Oh,
I
can
find
the
chat
again
tristan
had
to
take
off,
but
he
put
a
note
in
the
agenda
document
about
to
move
about
how
to
move
forward
with
a
release
announcement
and
apparently
there's
a
group
announcement
with
javascript
and
erlang.
So
we
can.
We
can
join
that
group
if
we
are
interested.
C
D
B
C
He's
pretty
active
on
cncf
slack
as
well.
If
you
respond,
if
you
ping
him.
D
B
There
may
have
been
I
kind
of
got
pulled
away.
Unfortunately,
like
I
said
I
caught
pieces
and
parts
of
it.
I
have
this
on
my
like
I'll
link
it
here,
something
that
I
need
to
read
it
essentially,
I
think
they're.
B
These
meetings
are
a
little
bit
unstructured
at
the
moment
and
they're
trying
to
add
structure
to
them
so,
like
one
of
the
things
is
like
coming
up
with
like
a
set
of
approvers
and
scoping
things
and
like
actually
taking
these
conversations
and
turning
them
into
something
a
little
bit
more
tangible
because,
like
even
if
we
reach
consensus
on
a
call
on
something,
it's
then
what
right
like
a
lot
of
this
is
just
a
bit
nebulous
people
are
talking
about
things
they
think
are
important
and
we're
trying
to
like
focus
it.
B
So
this
is
someone
proposed
like
how
we
should
get
the
http
semantic
conventions
to
a
stable
state
like
this
is
like
like
how
we
should
get
there,
basically
other
than
that.
I
missed
a
good
chunk
part
way
through,
but
I
caught
a
bit
of
the
intro
here,
and
so
this
is
just
yeah.
I
don't
know
how
much
more
I
could
share,
because
I,
like
just
realistically,
was
distracted
at
that
time,
which
kind
of
sucks,
but
those
are
like
the
big
takeaways,
is
like
pushing
for
some
stability.
Here
there
was.
B
B
B
Yeah
those
are
like
the
big
three
things
we're
just
like
coming
up
with.
How
do
we
actually
turn
things
into
actual
items
outside
of
the
meetings,
the
scope
for
http
stuff
and
then
pushing
that
these
http
attributes
required,
and
then
there
may
have
been
other
stuff?
I
missed,
unfortunately,
sorry
this
kind
of
allows
the
update.
A
D
B
A
Cool
all
right.
D
D
Yes,
we
didn't
bring
those
and
yeah.
I
jumped
right
into
the
thing,
but
we
should
we
should
celebrate
this
1.0
that
only
took
two
years
to
reach
called
the
party
popper.
Oh
party
power,.
D
Yeah
so
congrats
everybody.
Thank
you
thanks,
everyone
for
all
the
hard
work
it
would
not
have
been
possible
without
without
everybody
here
and
many
people
who
are
not
here
so.
B
I
have
something
to
that.
I
wanted
to
talk,
looks
like
really
quickly
in
terms
of
our
our
rack
instrumentation,
so
we're
seeing
really
really
hot.
B
My
back
out,
you
hear
me:
yes,
all
right
cool.
I
wanted
to
quickly
just
talk
about
the
rack.
Instrumentation
they're
gonna,
push
up
a
change
today
when
we
like,
with
rack
with
rails
rails,
will
override
the
span
name
when
it
matches
against
a
controller,
but
if
it
doesn't
we're
getting
really
high
cardinality
spans
and
the
spec
says
that
we
shouldn't
be
doing
that,
and
I
did
like
a
really
quick
scan
of
like
js
and
go
and
they're
they're,
not
overly
consistent
between
the
two
like
go.
B
For
example,
what
they'll
do
is
they'll
set
it
open,
they'll,
send
it
to
you
like
http
method,
no
route
match
I'll
set
that
as
a
spam
name,
whereas
I
think
js,
I
don't
have
the
tabs
open,
I
don't
know
where
they
went.
They
will
they
will
just
put
like
unmatched.
I
think
so.
It's
like
I'm
wondering
what
we
should
do
there
like.
What
would
you
want
to
like
copy
there,
because
it's
not
actually
specked
out?
B
I
was
thinking
of
just
taking
the
go
approach,
even
if
it
is
a
little
bit
wordy,
but
just
doing
like
http
method,
name
and
then
mac
like
route,
not
matched
or
something
like
that
or
unmatched
route
or
route
not
found
and
setting
that
as
the
default
fan
name,
you
can
always
override
it
with
like
your
rails
instrumentation,
I
think,
probably
should
have
like
a
hash
there
for
a
config
option
to
say,
like
I
just
want
to
use
the
url
name.
Does
anybody
have
any
strong
feelings,
then.
F
I
just
need
clarification
so
the
problem,
so
this
would
be
changes
to
the
rails
on
instrumentation,
not
to
the
rack
on
the
instrumentation.
B
F
Okay,
so,
instead
of
putting
the
url
in
so
for
the
url
quantization.
F
Right
now,
won't
we
you're
saying
that
it
would.
We
would
be
changing
the
default
rack,
the
default
method
name
to
be
sorry,
the
default
band
name
to
be
what
again.
F
B
B
Well,
the
idea
is
that
the
higher
level
should
match
it
like.
I
guess
we
have
to
decide
like.
That's
like
I
think
I
want
to
bring
this
up.
Is
that
if
you
have,
if
you
submit
like
a
quantization
method
to
it,
it'll
use
that
first,
if
you
say,
use
like
this
full
url,
because
that
should
be
a
config
option,
this
doesn't
exist
and
then
the
default
fallback
is
like
if
nothing
renames
the
stand
name.
B
F
So
we'll
be
keeping
track
of
the
before
and
after
what
this
band
name
used
to
be
in
the
rack,
middleware
itself
and
then
saying,
if
that
hasn't
changed,
then
we
set
it
to
you
know
whatever,
and
this
is
helpful
in
cases
where
some
bot
is
like,
scraping
your
site
and
you're
trying
to
hit
random
things
and
the
route's
not
really
found
right,
and
it
just
like
reduces
that
cardinality
or
like
you
know,
basically,
but
nothing
itself
is
translating
that
span.
Name.
B
B
Yeah,
so
if
we
look
at
like
open,
telemetry
goes
the
gorilla
instrumentation
there,
it's
if
it
can't
match
it.
It
literally
just
says
like
here:
http
method,
no,
not
them
and
the
js
stuff
was
doing
similar.
I
don't
have
the
link
for
that
right
now,
but
it
did
look
very
similar.
F
I
would
lean
towards
more
having,
personally
speaking,
lean
towards
having
the
span
name
be
named
like
the
hp
method.
Maybe
with
you
know,
because,
like
you
know,
we
end
up
having
a
bunch
of
things
that
are
saying
has
not
found
just
because
the
something
else
didn't
overwrite
it
for
some
reason.
E
Yeah-
and
I
think
that's
also
more
consistent
with
the
language
in
the
spec
I
mean
the
language
in
the
in
the
spec
is
mostly
talking
about
client
spans,
where
you
don't
have
enough
information
to
determine
the
route,
but
in
this
case
that's
also
true.
We
don't
have
enough
information
to
determine
the
route
because
it
didn't
route
to
anything
meaningful.
C
Would
this
information
be
I
the
data
dog
defaults
which
were
not
good
or
standardized
in
any
way
and
generally
hated
by
users
everywhere
were
some
like?
It
was
like
method
plus
status
code,
some
some
concatenation
of
that
which
sort
of
summarizes
or
encapsulates
like
if
it's
not
found
or
if
it's
like
you
know,
just
a
rack
app,
you
would
get
like
get
200
first
like
get
404
or
you
know,
I
don't
think
there's
like
great.
I
think
the
problem
is
that
all
the
solutions
are
ultimately
low
value.
C
So
it's
just
about
yeah,
I'm
not
picky,
but
I
think
it's
important
to
add
and
as
far
as
like,
I
would
love
to
see
a
quantity,
yeah
yeah,
but
I'm
not
picky,
but
I
agree.
It's
pro.
E
Yeah
I
mean
we
have
the
quantization
support
there,
like
there's
a
support
for
a
quantization
function
to
be
provided.
You
know
at
some
point
somebody
who's
eager
could
go
off
and
work
on
a
decent
quantization
function
that
we
could
provide
in.
You
know
like
the
common
package
or
something
right.
It's
just
a
utility
thing
that
people
can
can
leverage,
at
least
as
an
example,
but
I
think
the
default
should
probably
just
be
http
space
method.
C
B
So
er,
then
we're
going
to
say,
like
I
think
people
picked
up
on
the
conversation
right
like.
Are
we
comfortable
with
having
the
default,
be
like
http
method,
name,
okay
and
then
I
I
think
it's
not
unreasonable
to
surface
a
configuration
option
that
says
like.
I
would
like
to
continue
having
the
full
url.
As
my
name
like.
Do
you
think
it's
reasonable
to
give
that
functionality.
F
D
Yeah,
I
think
http
verb
name
makes
sense.
I
don't
know
how
relevant
this
issue
is,
but
I
think
this
seems
to
assume
that
you
have
a
low
cardinality
path
for
a
lot
of
these.
So
I
don't
know
that
this
exploration-
I
don't
know
how
complete
this
exploration,
was
to
figure
out
how
things
work
in
some
other
more
edge
case
scenarios.
D
But
yeah,
I
believe
that
that
http
verb
was
a
very
common
name,
at
least
in
open
tracing
for
http's
fans.
So
there
is
some
precedent
there.
D
C
I
have
small
stuff
I've
been
poking
around
at
that
there's
the
the
guy
chris
who's
contributed
that
really
useful,
like
high
query,
params
config
option
and
it's
sort
of
ballooned
into
like
well.
Let's
add
a
bunch
of
awesome
stuff
like
oh,
that,
like
it
sparked
a
lot
of
conversation
about
like
this
should
be
supported.
C
C
I
think
it's
starting
to
get
to
a
point
where
I
would
prefer
to
reduce
the
scope
of
it
to
just
basically
ship
the
http
request
attribute
helpers,
which
would
allow
the
end
user
made
the
original
pr
to
start
using
the
high
query,
params
feature
and
then
open
a
new
issue,
a
new
pr
with
some
broader
changes
to
handling
configuration
options
which
might
include
adding
in
some
more
instrumentation
helpers
but
yeah.
C
I
don't
it's
been
open
forever
and
I
realized
that
it's
starting
to
get
in
the
way
of
the
original
purpose
of
the
user's
pr.
So
that's
one
thing
I
wanted
to
mention
is
I'm
probably
anyone
who
is
reviewing
that
I'm
probably
just
going
to
cut
out
a
bunch
of
the
stuff
and
open
a
new
pr
like
separated
out
into
dpr,
so
it's
a
bit
easier
to
manage,
and
that
was
yeah.
C
That
was
the
only
thing
I
I
did
open
another
having
spoken
with
robert
and
tim
and
francis
and
you
know,
internal
meetings.
I
think
we're
looking
into
schema
url
more
it's
something
on
our
plate
to
maybe
specify
a
little
more
clearly
what
that
implementation
would
require
in
ruby.
C
It
seems
like
it's
a
little.
Although
the
otep
was
merged,
the
actual
use
is
a
little
bit
fluid
still
and
the
only
implementation
isn't
go
and
it's,
but
it
seems
like
there's
still
some
missing
parts
around
like
the
appropriate
way
to
maybe
parse
some
of
these
schema
urls,
but
just
I
added
a
sort
of
I
thought
I
did.
Is
there
yeah?
Oh.
C
We're
in
the
issues
not
to
be
ours,
I
added
a
placeholder
issue
to
kind
of
track
that
work.
It
seems
to
be
pretty
low
for
ruby.
It's
actually
a
little
bit
unclear
to
me
whether
the
otep
or
whether
this
work
means
just
add
this
sort
of
like
a
tribute
to
the
protos,
and
you
know
so
have
spans
emitting
with
the
schema,
urls
and
attribute
or
resources
or
whether
it
also
means
adding
the
functionality
that
schema
url
enables
which
is
having
this
automatic
translation
to
exporters,
essentially,
which
is.
E
E
C
Yeah,
it
seems
like
they're
kind
of
prototyping
wow,
like
they're
kind
of
doing
it.
Tigran
is
working
on
in
within
open
telemetry,
go
sort
of
iteratively
to
sort
of
prototype,
some
stuff
out
which
may
affect
what
the
ultimate
specification
looks
like.
But
we
can,
I
think,
do
it
incrementally,
where
the
lowest
hanging
fruit
is
just
adding
this
stuff
to
as
an
easy,
config,
optional
config
and
you
know
having
it
emitted
in
telemetry
which
can
be
ignored
and
then,
if
it's
required,
we
can
add
this.
C
You
know
it
seems
like
it
probably
probably
shouldn't
be
required
to
add
all
this
translation
stuff
to
an
exporter,
but
it
they
look
like
they're
attempting
to
do
that
in
open,
telemetry
go
because
they
want
they
don't
necessarily
want
to
depend
on
a
collector
with
it
to
make
use
of
the
functionality
which
makes
sense,
given
that
not
every
vendor
wants
or
requires
a
collector,
but
and
anyway.
So
it's
just
on.
I
just
opened
up
a
tracking
issue
and
I'll
probably
have
some
related
pr's
in
the
coming
weeks.
C
There's
still
lots
of
open
questions
around
the
feature
itself,
but
it
seems
pretty
cool
and
I
think
it
could
make
life
easier
for
us
if
we
do
decide
to
start.
You
know
if
stuff
starts
getting
breaking
changes
in
the
future
between-
I
don't
know
if
they
change
exception
to
you
know,
exception.name
to
be
exception.
C
error,
name
or
something
like
if
they
start
changing,
attribute
meanings
and
stuff,
it's
easier
to
track
it
and
manage
it
cool.
That
was
the
only
thing
I
don't
necessarily
have
open
questions,
but
if
anyone
has
thoughts
on
this,
you
know,
let
me
know
or
or
comment
on
the
pr
or
let
me
know
what
your
requirements
are
for
it,
because
I'll
probably
start
pushing
stuff
up.
D
Yeah,
I
think
it
would
be
interesting
to
get
an
update
at
some
point
to
it
once
once,
you
figure
out
exactly
what
needs
to
be
done
like
if
there
does
need
to
be
translation
in
process
and
if
that's
kind
of
like
an
optional
thing,
where
you
would
kind
of
do
it
either
in
process
through
configuration
or
kind
of
have
like
the
equivalent
thing
in
a
collector.
That
does
that.
C
There's
a
yeah
like
right
now,
there's
a
there's,
an
issue
to
add
that
processor
in
the
collector,
and
I
think
what
they're
doing
is.
I
think
the
blocker
right
now
is
merge.
It
there's
some
open
questions
around
how
you
merge
all
the
different
translations,
because
there's
different
subcategories,
some
of
them
overlap
with
each
other
and
then
there's
also
open
questions
around
like
well.
What
if
you
have
a?
What
if
you
want
to
do,
schemas
based
on
a
parent
schema,
so
it's
like
a
superset
type
schema.
How
do
you
merge
those
things?
And
so?
C
But
I
guess
by
doing
it
and
go
you
get
the
benefits
of
getting
the
work
kind
of
for
free
in
the
collector,
so
anyway,
cool
yeah
I'll,
try
to
I'll
try
to
keep
everyone
updated
on.
If
suddenly,
their
requirement
comes
down
to
us
that
we
have
to
implement
this
in
the
in
a
processor,
an
exporter
in
process
which
would
suck,
but
whatever.
D
E
Yeah
I
mean
it's
being
kicked
down
the
road,
primarily
because
the
spec
is
very
clear
that
once
you
finalize
that
span
and
turn
it
into
span
data
like
it,
the
the
span
itself
can't
be
modified
right.
We
have
to
turn
it
into
span
data
and
then
you
know,
presumably
the
span
data
can
be
modified,
but
yeah
you
can't
just
like
mutate.
E
I
think
there's
also
a
problem
in
that
span.
Processes
process
spans
not
span
data
right.
So
it's
really
just
that
final
one
that
produces
like
turns
it
into
span
data
and
emits
it
to
the
exporter.
So
most
of
the
use
cases
for
span
processes
are
assumed
to
be.
You
know
some
kind
of
batching
mechanism
or
just
simply
passing
it
on,
but
the
reality
is
that
you
want
to
mutate.
E
D
Yeah,
I
think
that's
exactly
what
we
need.
It
goes
after
the
spam
processor
and
you
can
get
your
hands
on
a
span
data
and
do
whatever
you
need.
Do
it,
but.
E
B
I
think
maybe,
like
the
last
thing
I'll
just
like
throw
it
out
there,
the
the
active
support
stuff
that
tim's
been
working
on
we're
about
to
merge
his
open
pr.
I'm
just
gonna
get
him
to
add
some
comments,
so
we
know
there's
actually
still
an
issue
so
there's
different
ways.
You
can
subscribe
your
notifications
so,
like
you
can
do
the
instrument
that
you
just
like
pass
in
the
block
that
works.
B
Fine,
you
can
have
like
the
conflicts,
notif
notification
subscription,
where
you
explicitly
define
your
start
and
finish
methods
if
the
finish
method
breaks
yeah.
So
you
can
see
that
there
is
the
example
of
where
it
breaks.
If
you
have
the
subscriber
and
it
breaks
in
the
start,
your
finish
will
never
get
called
on
your
spam
subscriber.
B
So
it
doesn't
matter
in
what
order
things
are
in
if
it
blows
up
there,
it
blows
up
the
whole
life
cycle
of
like
calling
finish
on
all
the
other
instrumentations,
so
there's
still
a
hole
here
where
it
doesn't
work.
This.
This
issue
existed
in
the
previous
implementation,
with
the
custom
fad
out
as
well.
B
Ultimately,
I
think
we're
just
running
into
the
fact
that
active
support
notifications
are
as
reliable
as
we
originally
thought
they
were
and
that
they
are
not
but
yeah.
This
is
like
our
next
step
once
this
gets
brought
in
he'll
continue
on
like
splitting
it
out
into
its
own
gem,
so
people
can
use
it
at
their
own
discretion.
B
We're
gonna
talk
to
some
of
the
internal
rails,
people
that
we
have
at
shopify
to
see
if
they
have
any
ideas
of
what
we
can
do
here,
but
this
just
solidifies
that,
like
I'm,
going
to
continue
avoiding
using
active
support
notifications
for
instrumentation
or,
if
possible
or
entirely
so,
it's
kind
of
the
grim
update
on
that
work.
E
I
mean
it's
not
a
mystery,
we
know
the
behavior
it's
just
well.
Maybe.
F
We
want
right
source
of
words
on
my
part,
it's
kind
of
like
the
crime.
Sorry,
it's
still
poor
choice
of
words.
We
all
knew
this
was
a
problem.
We
just
did
the
work
and
proved
even
more.
That
was
a
problem.
D
All
right,
yeah,
the
only
thing
I
was
going
to
say
is:
if,
if
we
are
able
to
come
up
with
some
sort
of
like
solution
with
rails,
core
people,
if
there's
some
clever
way
out
of
this,
that
can
be
added
to
rails,
you
know
future
rails.
D
We
could
always
consider
monkey
patching
past
rails
to
kind
of
have
have
that
behavior
and
that
might
be
that
might
be
one
escape
patch.
It's
my
only
optimistic
comment
on
this.
I
guess.
B
Yeah,
I
think
I
think
that's
fair,
it's
just
it.
It
just
becomes
a
little
bit
uncomfortable
with
how
invasive
it
gets.
If
we
take
that
approach
like
because
like
then
it's
it's,
we
do
that.
We
have
to
make
sure
that
it's
very
transparent
that
we're
doing
it,
because
what
if
some
application
somewhere
is
relying
on
the
fact
that
when
an
instrumentation
or
active
support
notification
blows
up
all
the
other
ones
don't
run,
I'm
sure
there
is
an
app
out
there
that
depends
on
that
behavior.
B
E
One
thing
I
was
just
going
to
say:
I
think
we
need
to
work
on
getting
like
first
party
open,
telemetry
instrumentation
into
rails.
That's
really
the
only
path
forward.
B
C
What's
gonna
say:
schema
url
is
supposed
to
help
with
first
part
instrumentation,
although
it's
unclear
how,
but
you
know
it's
like,
we
could
also
always
offer
new
relic.
Did
this
years
ago,
like
a
dual
option
for
like
here's.
Here's
how
you
tell
us
how
you
want
to
patch
your
stuff.
You
can
have
this
super
invasive
approach
or
use
asn,
and
you
know,
use
this
and
let
people
toggle
not
perfect,
but
kind
of
at
least
give
people
the
menu
of
choices.
C
G
I
think
it
like
solves
the
issue
of
discarding
the
active
support
notification,
so
that's
step
in
the
right
direction.
I
think
it
keeps
them
so
that's
good,
yeah
I'll
try
to
reach
out,
as
robert
mentioned
to
the
internal
rails
folks
and
try
to
summarize
it
in
an
issue.
D
Great
well
is
everybody
around,
I
think
yeah.
We
should
definitely
reach
out
to
to
get
in
on
this
group
1.1
announcement,
but
that.
F
I
will
throw
something
out
there.
Something
weird
is
going
on
where,
after
I
upgraded
to
1,
0
and
upgraded
net
http
and
the
exporter
gems
in
one
of
our
apps,
for
whatever
reason
it's
generating
spans
for
the
exporter
calls
sometimes
and
those
should
be
untraced
and
I
can't
reproduce
the
problem
outside
of
the
application.
F
So
I'm
in
this
weird
state
right
now
where
I'm
like
gonna,
have
to
debug
docker
hell
or
whatever,
to
figure
out
what's
going
on,
but
I'll
get
back
to
you
all
on
it.
C
I
used
to
see
it
all
the
time
at
date
or
dog,
because
we
had
a
bad
way
of
doing
on
tracing.
You
know
short
term
try
to
drop
them
where
you
can
and
like.
If
there's
ways
you
can
filter,
but
no,
I
yeah,
I
looked
at
the
commit.
I
didn't
see
any
changes
super
recently
related
to
that
anything
in
involved.
So
I
was
like
nothing
stood
out
to
me,
but
I
haven't
attempted
to
reproduce.
F
F
Because
it
is
generating
the
spam,
it's
just
that
the
untraced
parent
context,
essentially
that
the
somehow
maybe
the
parent
context
is
not
not
being
treated
as
untraced
for
some
reason,
and
so
I'm
really
confused.
C
F
That's
right,
we
provided,
I,
you
know
I
figured
I
was
like.
What
could
it
be?
I'm
you
know
we
use
our
own
metrics
reporter
implementation.
Are
we
initializing
that
class
out
of
order?
I'm
like
no?
None
of
those
things
make
sense,
because
if
it
was
like
a
initialization
problem,
then
the
instrumentation
wouldn't
be
mixed
in
at
all.
F
C
C
Yeah,
I
don't
have,
I
don't
have
good
ideas,
but
I
reckon
I
believe
you
if
that
makes
you
feel
better.
B
E
B
E
Export
pipeline,
so
that
we
could
actually
trace
the
export
call
and
then
the
collector
you
know
trace
it
all
the
way
to
the
collector,
basically,
okay,
so
we've
disabled,
that,
like
we
haven't
gotten
that
whole
chain
working
properly,
yet
so
we're
in
the
process
of
disabling
it.
I
don't
think
we've
disabled
it
yet
at
the
exporter,
but
we
we
want
to
so.
B
Yeah,
maybe
we'll
see
it,
but
I
was
just
wondering
if
maybe
it's
something
around
retry
when
it
fails
and
retries.
Maybe
it's
doing
something
peculiar
to
there,
but
I
don't
know
we'll
look
at
it
too,
because
I
can.
I
can
actually
get
that
going
today
and
have
us
stop
tracing
it
and
then
see
if
we
start
seeing
these
kind
of
fleeky
traces
coming
out.
F
Sorry
does
anybody
have
more
time
to
stick
around
or
you'll
we're
going
to.
B
F
B
F
F
Okay,
so
I'm
just
going
to
look
right
here
at
some
of
this
code
together.
Is
that
all
right
sure
so
looking
at
a
round
request,
this
is
setting
that
to
untraced
explicitly
correct
right,
like
this
should
just
work,
the
way
that
it.
F
Perhaps
it's
everything's
slow,
so
a
round
request
right,
which
occurs
here
at
line
149
right.
This
is
specifically
the
entire
block.
B
F
You
know,
and
so,
if
there's
any
retries
or
anything
that
happens
with
these
back
offs
or
whatever,
but
that
round
request
is
being
wrapped
here
by
this
untraced
on
this
on
the
common
utility
right
and
untraced
is
setting
a
non-recording
span
for
the
span
context
correct,
so
that
should
never,
and
so
I'm
wondering
I
got
a
little
bit.
I
was
a
little
confused
when
you
said
you
were.
You
were
looking
at
enabling
tracing
for
this
plan
for
y'all,
so.
F
Understood
so
you're
you're
a
overriding
request
in
your
applications,
so
you
can
trace
that
understood,
okay,
but
everything
here
would
lead
me
to
believe
that
this
should
always
have
a
parent,
a
non-recording
span
for
a
parent
context.
A
F
And
so
the
only
thing
that
I
can
think
of-
and
so
when
I
look
at
say
like
the
trace
output
right.
So
this
is
the
this
is
the
light
step
trace
software.
Unless
I'm
misunderstanding
this
right,
this
is
trying
to
hit
so
the
the
lightstep
satellite
which
is
effectively
like
their
collector
right.
This
is
a
different
url
for
the
http
target
and
this
is
our
our
host
name.
F
There
was
nothing
in
here
that
I
saw
that
I
felt
like
was
unusual,
but
I
did
see
that
we're
getting
a
parent
id,
so
there
is
a
a
parent
span
id
and
a
parent
trace
id
at
the
time
that
this
code
is
running,
and
so
I
don't
understand
how
that
would
be
possible
unless
something
was
weird
with
the
thread
context.
E
E
So
that
is
suggesting
maybe
there's
a
difference
in
sampling,
because
the
samplers
could
choose
like
the
samplers
later,
I'm
not
mistaken.
The
always
sampler
isn't
going
to
honor,
whatever
the
parents
doing
so,
there's
a
possibility
that
if
you're
just
using
an
always
sampler,
it's
always
going
to
produce
a
recording
span
like
it,
because
we're
explicitly
explicitly
saying
non-recording
span,
this
one
won't
be
exported,
but
its
children
might
be.
E
It's
one
of
the
it's
one
of
the
weaknesses
of
this
approach
of
untracing,
as
opposed
to
some
of
the
ones
that
were
being
proposed
by
javascript.
I
think
like,
if
you're
using
this
special
mechanism
in
the
context
that
allows
you
to
say
like
untrace
everything
from
this
point
on,
then
it's
more
robust.
This
doesn't
require
any
changes
to
the
context
api,
but
it
is
prone
to
problems
if
you
using
like
an
always
sampler
that
ignores
the
parent.
E
F
Okay,
how
do
you
normally
end
your
shopify
stand-up
meetings?
We.