►
From YouTube: 2021-07-13 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).
E
E
A
E
Oh
rob
I
was
going
to
mention
to
you.
I
am
also
having
problems
getting
the
action
view.
Instrumentation
to
work
is.
B
B
E
B
Had
sprinkled
some
judicious
put
statements
and
had
noticed
that
the
initial
eyes
in
that
fan
out
variant
wasn't
getting
called
yep.
That
is.
B
Then
the
stacks
wouldn't
line
up,
I
was,
I
think
I
had
put
statements
into
the
attach
and
the
detach
to
watch
the
stack
size
and
the
token
that
it
got
and
saw
that
they
would
get
out
of
sync.
At
a
certain
point,.
E
Yeah,
I
don't
know
why
that
isn't
getting
replaced
like
that.
I
think
it's.
I
suspect
I
have
just
invoked
the
initializer
incorrectly.
Somehow
I
it's
it's
a
rail
tie
and
there's
an
initializer
method
and
you
pass
it
a
name
and
like
a
before
after
specification.
E
My
current
gut
feeling
is
that
I've
told
it
to
run
before
an
initializer
that
doesn't
exist
in
this
rails.
App.
Somehow
that's
my
first
thought,
but.
B
And-
and
it
did
appear
to
be
working
in
a
in
a
super
micro
rails,
app
one
of
those
like
pull
it
from
the
rails
project
test
suite
where
it
all
runs
in
one
file.
I
can,
I
can
make
it
work
there,
but
I
can't
make
it
work
and
like
be
not
that
much
more
complicated
like
rails,
knew
me
a
thing
and
make
it
do
a
couple
things.
E
E
Yeah
I'll
see,
if
I
can
find
some
time
today,
I'm
a
little
bit
packed
out
with
stuff
in
the
afternoon,
but
I'll
I'll
take
a
look
and
see
what
I
can.
C
Hello,
everyone
sounds
like
yeah.
I
came
in
that
conversation
a
little
bit
late,
but
it
sounds
like
there
are
some.
This
is
the
the
action
view
instrumentation
that
the
things
rob
was
sitting
in
his
test
app
are
are
legitimate
in
some
way.
E
Yep,
the
we
we
try
to
replace
the
active,
active
support
notification,
queue,
implementation
because
rails
lets.
You
do
that
and
we
were
doing
it
with
an
initializer,
but
that
initializer
isn't
getting
run
in
some
of
our
rails.
Apps,
it's
getting
run
in
our
trivial
rails,
apps,
but
not
in
our
more
complex
ones.
It's
a
little
bit
of
a
mystery,
but
probably
a
solvable
mystery.
Just
you
know
digging
around
in
the
parts
of
rails
that
people
don't
actually
touch
all
that
much.
E
So
it's
not
clear
to
me
why
it
runs
the
initializer
in
some
apps
and
not
others,
but
it's
not
like
running
it
late.
It's
just
not
running
it
at
all.
So
that's
a
little
bizarre,
but
we'll
figure
it
out.
C
Yeah
these
things
can
get
complicated.
I'm
not
sure
that
I
have
any
advice
off
hand
other
than
if
you
could
use
the
active
support
like
on
load
hooks.
That's
what
those
are
called
those
those
help.
A
lot
is
that
what
those
are
called.
E
I
didn't
know
that
they
had
an
unload
hook
themselves,
but
if
they
do
yeah,
that
could
be
one
way
to
do
it.
We
were
trying
to
run
the
initializer
after
active
support
loaded.
The
rails.
Docks
imply
that
there's
that
there's
a
load
hook
called
like
load
active
support,
and
you
can
run
it
after
that.
It's
possible,
maybe
that's
new,
maybe
that's
why
it's
not
working
universally,
but.
C
Yeah
yeah
I'm
not
entirely
crazy.
I
think
I
will
share
my
screen
in
hopes
of
I
don't
know
backing
that
comment
up
to
some
degree.
C
So
it's
these
lazy
load,
hooks
sort
of
thing
act
to
support
that
on
load
component
and
like
yeah
in
general,
like
these
are
a
good
thing
to
use.
I
think
any
time
you're
going
to
reference
a
rails
constant
in
like
the
initialization
phase
in
these
hooks
because,
like
rails,
makes
heavy
use
of
like
what
is
it
auto
load
yeah,
where,
like
you
know,
kind
of
like
lazily,
you
know
require
a
constant
when
it's
referenced
and
if
you
reference
the
constants
at
the
wrong
time,
you
can
kind
of
mess
up.
C
It
seems
like
it's
a
delicate,
it
seems
like
rails.
Initialization
is
delicate
to
begin
with
yeah.
It
is,
and
this
helps
this
helps
with
some
of
that
stuff.
Yeah.
E
C
C
C
Cool
so
yeah
for
the
most
part,
it's
the
regular
crew,
although
I
see
one
new
face,
tim
welcome
so
yeah.
We
have
this
agenda
here.
If
you
have
anything
that
you
are
particularly
interested
in,
feel
free
to
add
it,
it
seems
like
you
are.
You
are
friends
with
our
shopify
contributors.
F
This
is
true
yep
true,
I
just
joined
roberts
and
francis's
team
at
shopify.
C
Cool
great
well
yeah
welcome,
usually
we
kind
of
just
run
through
a
a
recap
of
the
spec
sig.
We
try
to
do
that
in
less
time
than
the
specs
they
took.
It
usually
happens.
I
just
kind
of
talk
over
things
in
in
our
repo
feel
free
to
chime.
In
with
comments.
C
So
I
think
we
talked
about
this
last
time
and
in
general
I
think
there
is
there
there's
kind
of
this
recognition
that,
with
our
resource
detectors
and
in
general,
with
resource
attributes,
some
of
them
are
very
important
for
identifying
the
application,
and
then
some
of
them
are
kind
of
like
less
important
but
still
kind
of
carry
some
descriptive
information
with
them
and
for
for
spans,
the
distinction
between
that
information
doesn't
matter
all
that
much,
but
for
many
metrics
systems
it
does
matter
they're
sensitive
to
kind
of
cardinality.
C
So
if
you
have,
if
you
have
any
resource
attributes
that
that
have
high
cardinality,
it
causes
these
systems.
Some
problems,
there's
this
desire
to
kind
of
like
be
able
to
split
your
resource
attributes
into
two
buckets,
descriptive
and
identifying,
and
then
the
the
metric
system
can
just
grab
the
identifying
attributes
and
kind
of
get
a
set
of
low
cardinality
attributes
to
attach
the
metrics
and
the
tracing
system
can
take
all
of
them.
C
Things
I
I
think,
I'm
a
little
bit
less
unsure
of
is
it's
talking
about
a
schema,
and
there
was
like
mentioning
of
like
a
a
schema
url
that
you
identified
for
your
for
your
resource
and
there
would
be
a
default
one
that
you
could
use
or
you
could
use
custom
ones
like
that
whole
scheme.
C
G
I
mean
this
feels
somewhat
specific
to
a
given
organization's.
You
know
deployment
topology
right
things
that
matter
to
one
organization
may
not
matter
at
all
to
another
organization,
so
I
think
it
would
be
really
hard
to
specify
this
in,
at
least
in
the
global
schemer
I
mean
it
would.
It
would
also
be
super
frustrating
for
every
organization
to
have
to
go
through
that
global
schemer
and
tag
all
the
things
that
you
know
effectively
create
their
own
version
of
the
schema
that
is
tracking
the
upstream
schema
and
adding
an
indication
of
whether
it's.
G
Identifying
or
descriptive
right
so
it
just,
it
seems
like
a
really
hard
and
messy
problem
to
solve,
at
least
in
in
a
generic
fashion.
C
Yes,
I
definitely
think
I
definitely
agree
with
those
statements
from
from
the
way
this
is
written
would
would
a
user
have
to
like?
Would
they
have
to
host
their
scheme
on
somewhere
and
actually
pretty
much.
G
Yeah,
there's
sort
of
an
expectation
right
now
that
everybody's
going
to
use
the
the
global
schema
and
then
the
global
schema
will
evolve
over
time
and
and
that
will
be
versioned,
but
the
spec
allows
people
to
supply
their
own
schemas.
I
just
think
schema
management
is
going
to
get
horrendous
once
everybody
starts
hosting
their
own
schemas
and
then
trying
to
maintain
them
in
some
way.
It's
just
going
to
be
a
really
really
messy
thing.
C
G
G
G
A
But
but
one
thing
that
doesn't
connect
if
the,
if
it's
disjoint
from
actually
taking
the
schema,
how
are,
is
there
other
configurations
that
we
have
to
provide
the
client
sdk
to
say
these
are
descriptive
versus
these
are
identifiers.
G
Well,
actually,
yeah!
So
that's
a
good
point.
I
guess
the
the
way
this
is
suggesting
the
schema
based
proposal
would
work,
the
schemer
itself
would
describe
which
things
are
descriptive,
which
things
are
identifying,
and
so
the
client
would
have
to
pull
that
schema
in
order
to
figure
out.
You
know
how
to
do
the
label
mapping
on
metrics.
G
G
That's
going
to
be
challenging
yeah,
yeah
and
then
sorry.
G
It
came
in
version
1.4
of
the
spec,
so
we're
trying
to
meet
1.0.
We
don't
really
need
to
do
the
schema
support
for
a
little
while,
so
we
can
wait
until
we've
pushed
out
1.0.
They
specifically
wanted
to
allow
people
to
ship
1.0
without
this
schema
support.
So
they
didn't
want
to
push
a
new
requirement
on
people,
so
we
can.
We
can
implement
it
whenever
we
want
before
1.0
after
1.0
it
doesn't
matter.
I
think
I've
got
an
issue
open
for
this
already,
but
it
doesn't
block.
E
C
So
I
guess
this
is
a
proposal.
I
think
we
all
agree.
It's
a
little
bit
interesting,
so
I
guess
we'll
continue
to
follow
it
if
it
is
like.
I
don't
know
if,
if
anybody's
fuzzy
senses
things,
this
is
like
a
horrible
idea
like
the
sooner
you
speak
up
the
better.
I.
A
A
C
Yeah,
I
think
a
lot
of
that
makes
sense.
I
think
in
general,
most
people
will
be
using
an
open,
telemetry
collector.
I
do
think
they
there
is
this
desire
that
you
don't
have
to
use
one
as
well.
So
that's!
I
think
why
some
stuff
ends
up
closer.
C
B
C
B
C
On
all
right,
moving
on,
we
talked
about
this
once
before
too,
and
I
think
I
didn't
reread
where
this
has
gone.
It
was
just
kind
of
briefly
mentioned,
but
let's
take
a
quick
look.
It's
basically
about
how
you
specify
an
http
endpoint
versus
a
grpc
endpoint.
So.
C
So
there
was
a
change
that
just
said:
use
schemed,
urls
your
endpoint
and
the
protocol
will
figure
it
out.
If
you
use
https
for
a
grpc,
then
it
will
use
the
secure
bit.
C
A
C
Not
like
a
standard
scheme
between
all
of
the
different,
like
grpc
implementations,.
A
C
Yeah,
no,
that's
fine!
I
was
just
trying
to
skim
this
to
see
what
the
summary
is
and
it
seems
like.
C
C
Yeah
seems
like
schemed
urls
are
supported
you,
you
have
the
option
to
implement
the
insecure
option
so.
C
C
C
I
think
the
tldr
is
it's
hard
to
have
one
like
way
to
describe
an
endpoint
that
grpc
users
and
http
users
are
going
to
be
totally
comfortable
with.
C
I
think
this
issue
there
is
some
concern
between
when
there
might
it's
yeah.
This
is
the
background.
Is
you
have
multiple
http,
potentially
multiple
http
instrumentation,
trying
to
modify
the
context
on
a
request.
C
C
C
And
I
think
in
general
in
general,
this
is
probably
what
you
want,
because.
C
I
guess
yeah,
like
your
your
trace,
would
branch
in
a
fairly
weird
way.
I
feel
at
that
request
at
that
request
boundary
if
it
worked
any
other
way.
E
I
think
this
was
referenced
in
it
was
referenced
in
an
actual
update
to
the
spec
that
they're
trying
to
make
which
would
forbid
client
spans,
nested
client
spans,
possibly
or
or
enforce
semantics
about
detecting,
if
there's
already
an
http
request
in
flight
and
then
modifying
creation.
Accordingly,
I'm
not
really
sure
exactly
that.
I
have
a
great
grasp
on
all
the
issues.
I
left
a
comment
on
the
pr
and
the
response
felt
a
little
dismissive
which
made
me
feel
like.
E
Yeah,
that's
the
that's
the
one.
I
actually
don't
really
like
this
pr
this
proposal.
I
agree
with
the
idea
of
de-duplicating
multiple
layers
of
instrumentation,
possibly,
but
this
feels
a
little
it
personally
to
me.
It
feels
a
little
over
prescriptive,
so
I
think
that
this
is
where
the
the
com,
that
issue
is,
is
kind
of
playing
out
a
little
bit.
C
E
E
I
think,
like
I
don't
know,
I
don't
know
how
to
communicate
more
broadly
to
the
open
telemetry
world
that,
like
there's,
actually
a
lot
of
stuff
happening
in
the
ruby
world,
we
actually
have
a
pretty
complete
implementation
of
things
at
the
moment
and
a
lot
of
instrumentation
and
a
lot
of
thoughts
on
this
stuff.
E
C
C
I
feel,
like
this
dovetails
a
lot
in
this
kind
of
instrumentation.
What
are
they
calling
it?
The
instrumentation
working
group
that
is
supposed
to
kind
of
be
improving
some
of
the
the
rough
edges
around
instrumentation
in
general,
but
it's
somehow
that
is
happening
at
the
4
p.m.
C
C
Yeah
I
do
agree.
I
think
that
at
least
this
group
has
thought
about
some
of
these
things
and
I
think,
has
come
up
with
some
pretty
decent
solutions
for
them.
E
But
I
think
the
value
of
us
participating
more,
and
I
think
I
am
going
to
start
trying
to
go
to
some
of
the
other
spec
meetings
is
that
we
can
share
alternate
approaches
and
visions.
I
think
a
lot
of
the
the
spec
is
being
driven
by
just
how
much
work
they're
doing
in
the
java
world
right,
like
they've,
got
a
ton
of
work
that
they're
doing
and
they're
moving
forward
and
formalizing
some
of
the
way
they
do
things
as
specification,
which
makes
sense
at
times,
but
at
other
times
it
it.
E
It's
probably
not
as
helpful.
So
I
think
yeah.
I
think
I
will
start
trying
to
get
to
some
more
of
those
meetings.
If
anyone
else
wants
to
go
with
me
just
to
kind
of
participate
in
the
discussion.
C
C
Agreed
all
right,
I
think
we
also
talked
about
this
one
recently,
there's
there's
a
pr
to
add
a
distro
identifier
to
the
resource.
C
So,
if
you're
using
a
custom
kind
of
distribution
of
open
telemetry,
which
probably
everybody
is
from
to
some
degree,
whether
it's
your
your
own
organization's
kind
of
open,
telemetry
stack
or
whether
it's
some
sort
of
you
know,
vendor
training
wheels
on
the
open,
telemetry
sack,
it
would
be
nice
to
kind
of
know
what
you're,
using
on
the
back
end
side
to
help
kind
of
track
and
or
diagnosis
issues.
C
C
C
C
Yeah
and
then
there's
just
kind
of
a
quick
update
on
the
metric
sig.
I
don't
know
how
much
anybody
from
this
group
has
been
looking
into
kind
of
where
the
api
is
headed.
But
apparently
it's
looking
great
and
they
are.
C
Of
freezing
that
soon,
so
I
guess,
if
we
haven't,
had
a
look
at
what
what's
going
on
in
the
api
world,
probably
should
be
forced
too
late.
C
So
I
don't
know
how
much
that
distinction
actually
means
they
both
sound
like
the
sdk
stuff,
is
still
fairly
early
on
as
far
as
specimens
as
far
as
specification
goes.
I
do
know
that
there
are
like
some
prototypes
happening
in
in
tight
and
untyped
languages,
so
I
believe
python
at
least
is
doing
quite
a
bit
of
work
on
on
an
implementation.
C
If
you
want
to
kind
of
see
what
they're
up
to
it
might
be
a
little
bit
more
similar
to
what
we
would
end
up
with
in
the
ruby
world
than
say
that
the
java
implementation
yeah,
the
histogram
format
for
otlp,
has
been
hotly
debated
for
a
long
time.
C
I
think
it
has
involved.
Like
I
don't
know,
everybody
who
knows
anything
about
histograms
is
the
who's
who
of
of
histograms
in
in
today's
era,
and
it
has
been
incredibly
complicated.
I
think
there's
a
lot
of
like
implementations
out
there
that
are
suitable
but
like
there
are
like
patents
and
copyrights
and
other
legal
issues
around
them
all,
but
it
seems
like
there's
some
traction
on
an
exponential
histogram
that
would
be
base.
C
Two
apparently
there's
like
a
base
10
log
linear,
which
is
like,
could
be
a
competitor,
but
I
think
it
seems,
like
things
have
swung
in
in
this.
C
Direction
if
anybody
understands
all
the
nuances
of
histograms,
I
would
be
interested
in
listening.
C
C
I
first
talked
about
a
little
bit
before,
I'm,
not
I'm
not
totally
sure
what
it
is.
I
my
my
probably
incorrect
understanding
is.
This
is
something
around
like
what
attributes
are.
C
Any
follow-up
conversation
on
any
of
these
issues,
or
should
we
start
talking
about
issues
and
prs
with
hotel
rui
look
back
at
the
agenda.
B
The
agenda
is
more
notes
than
it
is
respective
topics
at
this
point.
C
Cool
yeah,
that's
fine,
and
if
anybody
has
any
burning
questions
whatever
just
feel
free
to
surface
them,.
G
So
we've
got
a
dozen
issues
open
here.
One
of
them
is
assigned
to
eric
and
he
was
going
to
take
a
a
look
at
this.
Hopefully
he'll
have
time
to
dig
into
it
soon,
the
other
six
that
are
assigned.
I
took
a
look
at
all
of
these.
These
are
all
people
who
are
not
active
contributors
and
in
some
cases
you
know
grabbed
an
issue
back
in
like
october
last
year
and
haven't
touched
it
since,
so
I'm
inclined
to
just
unassign
all
those
six
and
yeah
they're
all
up
for
grabs.
G
If
people
want
to
contribute
to
these,
we
may
want
to
consider
just
punting
some
of
them.
It
depends
how
much
polish
we
want
for
1.0.
We
could
always
do
a
1.0.1
with
all
the
all
the
docks.
G
The
only
things
so
there's
a
spec
compliance
issue,
which
is
the
last
one
on
the
list
here,
which
eric
is
going
to
look
at
there's
actually
ignoring
links
within
valid
span
context,
is
also
a
spec
compliance
issue.
So
we
should
probably
add
that
one.
G
What
was
the
other
expect
compliance
one
that
was
on
the
list?
There
was
a
context-related
one
verify
that
no
baggage
is
stored
in
the
context
upon
empty
data,
so
this
is
really
just
taking
like
eric
was
going
to
look
at
this.
It's
just
take
a
look
at
the
code.
Make
sure
that
we
implement
that
requirement,
which
we
may
not
do
correctly.
So
we
should
just
double
check
that.
E
If
you
want
to
reassign
that
to
me,
I
could
I
could
probably
grab
that
this
afternoon.
Actually
I
was
planning
on
working
on
open
source
stuff
this
afternoon,
anyways,
okay,
you
you
might
want
to
just
reach
out.
E
Yeah
I'll
check
with
him,
but
I
can
probably
between
the
two
of
us,
we'll
get
it
done
very
soon.
I
was
going
to
say
I
think
we
should
punt
on
the
rest
of
it.
Docs
are
good.
We
can
keep
trying
to
write
docs,
but
if
it
I
don't
know
if
it
needs
to
block
the
release.
G
There's
configurator
improvements.
That
was
the
one
other
thing
that
like
affects
the
sdk.
Basically,
is
there
anything
that
we
would
want
to
change
before
1.0?
So
most
of
this
is
talking
about
the
hotel
propagators
thing,
so
we
have
an
hotel,
propagators
environment
variable
and
then
we
also
have
a
configurator.propagators
writer.
G
The
the
implementation
of
propagators
has
changed
completely
since
this
issue
was
open,
but
we
should
just
take
a
look
to
see.
Is
it
more
convenient
to
do
what
was
requested
here
with
the
new
structure
of
propagators,
or
is
this
still
something
that
we
want
to
address?
G
G
We
might
want
to
consider
that,
but
on
the
other
hand,
it
does
make
it
a
little
bit
more
complex
to
do
more,
complex
things
right
like
how
do
you
actually
set
up
your
propagators?
If
you
have
something
special.
E
And
unique
yeah
and
also
then
it
would
start
to
be
a
little
inconsistent
with
some
of
the
other
options
on
the
configurator,
like
the
expand.
G
E
Do
we
hate
the
idea
of
allowing
the
c
dot,
propagators
and
c
dot
span,
processors
or
whatever,
to
take
a
string
or
an
object?
And
if
it's
a
string
we'll
try
and
split
it
exactly
as
if
it
came
from
the
environment
variable
and
if
it's
not,
then
we'll
just
pretend
it's
it's
an
option.
The
flip
side
is
people
can
just.
G
B
Well,
at
least
we'll
be
dumb
together,
I
don't
know
yeah
if,
if
the
spec
is
like,
you
can
configure
it
through
this
way
and
the
spec
sort
of
specifies
the
configuration
api.
If
I
sort
of
hand
wave
what
api
means
then
we
can
make.
The
can
like
the
golden
path
is
for
you
to
like
set
an
environment
variable
either.
B
As
you
spin
up
your
process
or
in
your
ruby
and
the
the
library
will
configure
itself
as
appropriate,
and
if
you
need
to
get
fancy,
there's
the
configurator
so
like
don't
touch
the
configurator.
B
Unless
you
need
to
get
fancy
so
that
the
configurator
can
have
a
well,
I
don't
want
to
call
it
a
simpler
interface,
but
it's
not
as
complicated
as
dealing
with
the
golden
path,
like
yeah
interpret
the
environment
variable.
But
if
you
give
the
configurator
propagator
stuff,
it's
like
I'm
going
to
ignore
the
golden
path,
and
you
you
obviously
know
what
you're
doing
is
the.
G
C
C
I
think
the
the
idea
behind
this
this
is
actually
opened
a
while
ago
was
just
to
make
sure
that
that
we're
happy
with
the
configurator
before
shipping
things
like
yeah,
it
kind
of
evolved
to
make
configuration
easier,
and
I
think
it
did
do
that,
but
I
think
it
became
a
little
bit
hard
to
use
at
one
point,
but
I
think
things
have
actually
improved,
so
I
think
we've
improved
the
configurator
in
a
lot
of
ways
that
isn't
mentioned
here
over
the
last.
C
I
don't
know
eight
nine
months,
and
this
was
just
one
example
that
I
kind
of
dropped
in
here
of
like
how
things
were
kind
of
hard
back
then.
So
I
think
things
have
improved
here
like
yeah.
I
don't
necessarily
think
that
we
need
to
do
any
of
the
stuff
that
we've
discussed
here
today
unless,
for
some
reason
it
makes
sense,
but
I
would
definitely
I
would
definitely
or
I
would
prefer
to
not
make
like
propagation
some
special
case.
I
guess
so.
C
If
we're
going
to
like
do
something
nice
for
propagation,
it
should
also
work
for
span
processors
and
exporters
and
anything
else
too.
So
I
would
favor
some
sort
of
consistency.
I
guess
over
like
some
weird
special
case
stuff,
just
for
context
problem
as
long
as
it's
slightly
better
than
this,
then
I
think
we've
improved
the
configurator.
C
E
C
So
I
think,
yeah
being
the
one
who
opened
this,
I'm
totally
happy
to
close
this.
I
think
we
should
just.
We
can
either
agree
now
that
everything
is
as
good
as
we
want
it
to
be,
or
we
should
just
agree
to
think
or
to
just
evaluate
that
the
configurator
has
what
we
want
and
if
so
then
close
this.
D
I'm
I'm
good
with
closing
it
like
I've,
come
back
to
this
and
thought
about
it
quite
a
few
times
and
honestly,
the
way
it
is
now
like
you,
you
have
all
of
the
overrides
necessary
everything
else
is
done
via
environment
variables.
Like
I
don't
know
at
this
point
in
time,
I
don't
know
what
I
would
change
to
make
it
better.
Like
there's
convenience
methods
for
setting
like
your
service
name
and
your
revision.
You
can
add
your
own
spam
process.
You
can
do
anything,
you
want
really
and
it's
it's
done
in
a
predictable
way.
D
That's
consistent
with
other
libraries
that
people
use
like
whether
it's
like
bug
snack
roll
bar
or
whatever,
when
you're
setting
it
up.
It
looks
very
similar,
similar
to
just
like
configuring,
external
gem
like
this,
so
I
don't
think
we
need
to
like
revolutionize
configuring
gems.
So
I
don't
know.
I
think
it's
good.
E
I
agree:
I'm
gonna
open
an
issue
to
ensure
that
our
documentation
and
examples
reference
the
environment
variables
whenever
possible
to
kind
of
guide
people
down
that
happy
path.
E
G
E
The
links
with
invalid
spam
context,
there
is
a
draft
pr
for
that.
Isn't
there
there's.
G
A
draft
pr
it
has
a
lot
of
problems
and
hasn't
been
updated
in
a
while.
We
may
either
want
to
reach
out
to
the
author
of
that
to
see
if
they're
going
to
address
those
concerns,
or
one
of
us
just
pick
it
up
and
do
it.
I
know
what
needs
to
be
done,
so
I
could
just
pick
it
up
and
do
it,
but.
D
I
I
grabbed
it.
I
think
I'm
going
to
have
tim,
do
it.
D
G
Yeah
and
the
other
one
is
the
timeouts
for
the
jager
exporter
and
the
zipkin
exporter.
Those
are
two
environment
variables.
Those
should
be
pretty
easy
to
add
support
for
so
yeah.
I
feel
like
that
is
a
good
first
issue.
G
I
haven't
been
staying
on
top
of
spec
updates,
so
it's
probably
worth
taking
a
look
through
the
spec,
particularly
the
list
of
environment
variables,
to
make
sure
that
we're
implementing
all
the
required
environment
variables
so
yeah.
If
anybody's
keen
to
do
that
and
open
issues
for
anything,
I'm
missing.
E
G
A
few
days
ago,
so
I
mean
we're
aiming
to
support
the
1.0
of
the
spec,
but
as
far
as
environment
variables
concerned,
I
don't
think
I'd
be
like
trying
to
look
back
in
time
to
look
at
the
set
of
environment
variables.
I
just
see.
Is
there
anything
in
that
list
that
we're
in
the
current
list
that
we're
missing
and
just
open
issues
for
them?
G
I
guess
we
can
decide
after
the
fact
whether
you
know
it's
a
ton
of
work
and
not
required
for
1.0
and
therefore
should
be
punted
or
or
if
we,
you
know,
they're
trivial,
and
we
should
just
add
them.
As
far
as
I
know,
there
are
no
spec
changes
or
clarifications
related
to
1.0
that
we
need
to
implement.
G
G
Sometimes
carlos.
G
C
We
all
talked
about
it
and
I
think
daniel
wrote
this
up
and
it
was
pretty
good.
I
think.
C
The
thing
I
I
don't
know
now
is
like
how
required
this
is,
I
feel,
like
most
languages
ended
up
with
a
document
and
in
their
repo
describing
the
versioning
process,
but
at
any
rate
like
it
would
probably
be
useful
to
have
something.
So
people
understand
what
oh,
what
our
version
numbers
mean,
but
I
think
the.
C
The
main
point
is
that
our
version,
the
number
itself,
carries
the
meaning
I
think
for
for
the
packages,
and
I
think
I
think
that
is
not
the
case
for
like
every
language,
there's
a
bunch
of
other
like
weird
schemes
that
different
languages
we're
talking
about
like
having
like,
for
example,
I
think
metrics
are
experimental.
C
So
I
think,
like
there
were
groups
that
were
discussing
all
right,
we'll
just
have
a
metrics
dash
experimental
package,
but
it
will
version
the
same
as
the
stable
kind
of
like
tracing
packages
and
then,
when
we're
no
longer
experimental,
we'll
just
change
the
name
or
something.
Whereas
our
document.
G
C
Cool
so
yeah
we
should
probably
we
should
probably
have
one
and
given
that
we
already
have
this
draft.
D
G
Yeah,
interestingly,
the
java,
the
java
one
just
has
a
versioning
section
that
that
links
back
to
the
spec.
E
G
Yeah
so
it
looks
like
we
should
probably
have
one
there's
a
few
different
examples
out.
There
java
has
a
versioning.md.
C
Yeah,
I
think
that's
true.
I
do
need
to
head
to
another
meeting
so
feel
free
to
carry
on
if,
if
there's
more,
to
carry
on.
D
I
have
just
a
small
one
just
to
see
what
like
people
thought
of
adding
more
specific
errors
to
like
some
of
our
classes.
Like
I
have
a
presented,
my.
D
D
So,
just
like
the
background
context
on
this
is
like
we
have
people
that
are
running
with
like
a
real
exporter
in
their
development
environments
and
rails,
as
we
know,
does
like
the
whole
boot
process,
which
will
initialize
tracing
and
if
they
don't
have
their
exporter
running
running
like
a
migration
will
fail
because
it'll
fail
to
export
span.
So
the
reason
it's
failing
is
we're
also
encouraging
people
in
development
environments
to
have
the
error
handler
raise
errors
so
that
they
can
catch
them
before
it
goes
into.
Production
gets
lost
in
the
logs.
D
The
idea
here
is
like
the
one
I'm
seeing
is
like
people
are
trying
to
run
jager
in
their
local
environment.
They
run
a
migration
and
it
fails
because
jaeger's
not
necessarily
running
when
they're
running
a
migration.
They
have
the
air
handler
configured
to
raise.
So
then,
like
it's
just
blowing
up
like
local
depth
setup
tasks.
D
D
What
I
want
to
do
is
be
able
to
filter,
on
certain
exceptions
like
I
want
to
be
forgiving
of
a
failure
to
export,
so
people
can
leave
this
setting
enabled
and
a
migration
doesn't
crash
because
it
didn't
export
to
year,
but
the
question
kind
of
circles
back
because
I
know
in
more
of
like
railsland
people
generally
discourage
adding
like
these
one-off
error
types
right.
They
say
like
use
like
the
standard
error
set,
but
I'm
not
sure
if
that
same
kind
of
sentiment
applies
to
like
gems
and
libraries
like.
D
D
B
Should
only
send
from
say,
standard
yeah
yeah
so
that
it's
easy
to
catch
but
yeah.
I
think
these
aren't
one-offs
coming
from
a
library.
These
are
a
library
telling
you
what
went
wrong.
Okay,
I'm
in
support
of
more
better
errors.
D
And
so
this
change
that
I
have
here
doesn't
actually
impact
the
behavior
of
it.
It's
just.
If
someone
has
an
error
handler
now
they
get
the
exception
class.
They
look
at
the
same
message
as
they
did
before,
so
the
longer
still
on
the
same
message
with
better
default
behavior,
so
only
in
the
event
that
they
have
like
an
air
handler.
That
does
something
special
with
exceptions.
Would
this
have
any
implication
for
consumers?
So
I'll
add
I
don't
know,
I
don't
know
if
this
should
be
considered
a
breaking
change.
D
D
It
just
like
it
uses
the
default
error
handler
so
like
if
you
don't
override
the
air
handler
it'll,
just
lock
a
message
now,
it'll
still
just
log
a
message,
but
if
you
override
the
default
error
handler
to
say
raise
when
you
reason
it
receive
an
exception,
it
would
start
raising
now
so
like.
This
is
a
really
specific
case
where
this
is
potentially
a
breaking
change.
I
don't
know
I
don't
know,
maybe
I'll
just
be
safe
and
call
it
out
as
a
breaking
change.
I
don't
know,
but
it's
it's
not.
D
D
The
other
thing
is
I'm
splitting
apart
the
the
action
controller
out
of
the
rails,
gym
and
giving
its
own
gems
so
that
the
rails
gem
is
just
gonna,
be
an
aggregator
of
like
the
other
stuff,
like
so
taking
some
of
andrew's
work
and
bringing
it
in
and
then
it'll
have
like
the
active
record
and
see
how
this
so
it'll
just
be
aggregating.
Instead
of
having
action
packed
like
built
right
into
the
rails
gem,
so
that's
something
I'm
hoping
to
put
up
soon.
D
The
other
thing
that's
like
the
bigger
question
that
I'd
like
to
talk
about,
maybe
on
the
next
take
is
we
have
a
lot
of
cool
environment
variables
for
a
lot
of
the
configuration
I'd
like
to
build
something
in
for
instrumentation,
so
that
people
can
override
or
set
values
in
their
environment.
That
would
save
disable
features
and
instrumentation.
D
E
Yeah,
that
would
be
nice.
I
would
be
happy
to
chat
about
that
later.
Actually,
right
now
we're
doing
it
in
our
rapper
gem
by
just
intercepting
basically
the
we
require
that,
like
you
know,
we
look
at
what
instrumentation
you've
told
our
wrapper
gem.
You
want
to
install
and
we
merge
in
default
options,
which
is
not
necessarily
the
most
ideal
way
to
do
it.
I
think
environment
variables
could
be
a
good
win
there.
D
D
But
I
expect
someone
to
want
to
modify
some
option
and
they're
going
to
ask
me
and
they're
going
to
say
how
do
I
do
this
and
the
only
option
I'll
provide
them
is
well.
You
can't
use
a
rapper
gem
and
you
have
to
configure
everything
yourself
from
scratch,
and
then
that
is
not
a
precedent
that
I
want.
So
I'm
thinking
ahead
a
little
bit
that
I
want
to
just
like.
D
Have
this
environment
override
and
just
have
it
done
dynamically
like
right
in
the
instrumentation
based
class
like
we
already
have
it
for
disabling
instrumentation?
There
is
an
environment
variable
that
allows
for
that,
but
that's
just
a
one-off
for
enabling
or
disabling
instrumentation
I'd
like
to
have
it
apply
to
all
the
configuration
options
for
each
instrumentation.
E
Yeah,
I
think,
there's
a
way
to
do
that
cleanly
in
a
way
that
works
well
with
the
the
options
in
the
instrumentation
base,
and
things
like
that.
I
think
we
could
do
that
pretty
well.
Actually,
yeah.
D
A
I
I
just
added
a
comment
for
it
because
I
don't
think
that's
going
to
set
the
back
trace
by
creating
initializing
the
new
exception
instance.
So
I
don't
know
if
folks,
with
their
own.
D
A
B
D
Okay,
I
will
try
to
find
one
that
illustrates
it
because
yeah
I
did
the
same
thing
in
context:
the
the
api
context
class
and
I
was
getting
the
behavior
I
wanted,
but
maybe
I'll
I'll
we
can
discuss
it
on
the
pr
I'll
do
like
a
little
counter
example
and
either
I
misunderstood
my
original
finding.
I
need
to
change
context
or
something
else.