►
From YouTube: 2021-04-27 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
How,
how
are
you.
B
Yeah
yeah
life's
good.
I
can't
complain
brother's
good
and
yep.
I
don't
know
no
exciting.
Do
it
nothing
exciting
in
my
life?
That's
okay!
B
Yeah!
How
are
you,
how
is
oh,
I
have
to
write
a
talk
for
your
conference
or
I
guess
y'all
and
lightstep
and
honeycomb
do
like
a
observability
conference
type
thing
or
like
there's
a
or
there's
a
lot
of
folks
from
those
and
I
volunteered
to
give
a
talk
and
then
realized.
It
was
a
25
minute
talk.
A
B
B
It's
it's
a
separate,
it's
not
it's
like
an
independent
conference,
but
I
know
some
ted
and
some
folks
from
your
side,
olliefest
observabilityfest
much
but
yeah.
I
thought
it
would
be
like
a
seven
to
ten
minute
talk,
which
is
it's
25
minute
talk,
so
I'm
like
trying
to
yeah.
I
don't
know
I
don't.
Have
I've
never
spoken
for
25
minutes
about
anything
in
my
life,
let
alone.
B
D
B
B
Careeralyze.Com,
there's
a
bunch
of
ex
datadog
people,
ex
cockroachdb
people
and
stuff,
but
I've
seen
their
name
pop
up
a
lot
and
I
was
like
oh,
this
is
my
latest
thing
to
be
to
not
do
the
work
I
have
to
do
so.
I
can
randomly
look
at
other
tech
companies.
B
Yeah,
I
never
I
kind
of
miss
doing
just
regular
like
product
engineering,
because
I
don't
have
a
chance
to
really
like
touch
a
lot
of
this
stuff
anymore.
They
look
cool.
E
Yeah,
it
actually
kind
of
is
interesting
like
querying
streaming.
Data
sources
is
kind
of
rough,
so
anything
that
makes
it
better
is
kind
of
cool.
B
E
Oh
yeah,
I
mean
that's
how
a
lot
of
those
threads
end.
I'm
like
okay,
nope.
No,
you
can't
just
close
the
thread.
C
E
B
C
C
Yeah,
just
let
me
know
if
this
is
not
coming
through:
okay
and
during
the
specs
egg.
Like
I
don't
know,
zoom
is
seeming
choppy
and
it
might
be
my
internet
connection.
So
if,
if
I'm
breaking
up
or
something
just
just,
let
me
know
I
can
try
pausing,
video
or
whatever.
C
Here's
our
agenda
think
about
your
burning
questions.
I
will
just
jump
into
this
effects.
Sig
update
because
there's
only
one
topic,
so
I
think
we
should
really
get
through
this
pretty
quickly
and
then
we
can
come
back
around
to
the
burning
questions
and
or
issue
pr
walkthrough,
so
the
js
sig
is
kind
of
going
through
a
tc
member
review.
C
I
think
this
is
like
a
thing
that
cities
can
sign
up
for
before
they
before
they
officially
declare
a
1.0
on
on
their
tracing
and
carlos
has
been
going
through
this
stuff
and
I
think
he's
been
doing
like
a
very
thorough
job
actually,
but
one
of
the
things
that
he
found
in
the
js
implementation
that
he
just
wanted
to
kind
of
ask
about
was
they
have
a
they
have
a
way
to
yeah.
So
I
guess
under
context.
There
is
a
method
called
suppress
instrumentation
and
it
sets
its
own
key.
C
It
works
different,
so
yeah,
it
kind
of
has
the
same
the
same
end
but
works
differently
than
our
untraced
method.
So
I
think
the
the
question
was:
can
you
do
this?
Is
that
all
right,
and
should
there
be
more
cooperation
at
the
spec
level
about
those
sorts
of
things,
and
I
at
least
brought
up
during
this
conversation
that
we
have
this
untraced
method
and
it
basically,
if
you're
not
familiar
with
it,
it
will
kind
of
it
will
use
withspan
with
an
api
span.
C
So
the
api
span
is
kind
of
like
an
invalid
span,
so
it
it
will
not
get
recorded
and
then
any
of
the
children
will
not
get
recorded.
So
I
think
correctly,
if
I'm
wrong,
but.
C
Exclusively
using
this
from
like
exporters
to
make
sure
that
we
don't
create
a
span
for
for
the
outgoing
http
request,
when
you
kind
of
post
your
spans
yeah.
C
I
think,
as
we
have
this,
I
think
we
are
in
good
shape
because
it's
in
this
common
utils
gem-
it's
not
like
part
of
the
api,
and
I
think
that
was
kind
of
the
the
main
concern
with
this.
But
daniel
dailo
was
going
to
kind
of
take
on
an
action
item
to
kind
of
write,
some
stuff
up
about
ways
that
this
could
be
done
in
a
more
uniform
way
across
open
telemetry.
C
I
guess
other
relevant
points
that
came
up
in
that
conversation.
Is
that
doing
it?
The
way
js
is
with
this
bit
on
context
like
you
can
affect
more
than
just
tracing.
You
could
affect
other
signals
with
it.
If
you
wanted
to
like
metrics
logs,
our
kind
of
approach
would
be
completely
focused
on
tracing.
F
C
And
I
think
the
other
thing
that
is
maybe
less
or
there's
pros
and
cons
of
all
these
approaches,
but
one
of
the
other
aspects
of
our
approach,
I
think,
is
that
I
think
it
gets
hard
to
turn
it
back
on
if
you
wanted
to
like,
if
you
wanted
to
nest
these
things,
it's
like
once,
you
have
an
untraced
block.
It's
like
everything
below
there
is
just
going
to
become
discarded.
C
So
if
you
wanted
to
be
more
fancy
and
like
skip
a
span
early
up
in
the
trays
and
then
have
them
everything
else
record,
I
think
you
can
do
this
with
this
context
approach,
because
you
would
still
kind
of
have
like
the
current
span.
The
thing
that
will
be
the
parent
of
the
next
thing
whenever
you
turn
it
back
on,
it's
still
still
around,
whereas,
like
we
kind
of
lose
that
yeah.
F
In
general,
any
mixing
of
api
spans
with
sdk
spans,
if
you
try
to
like,
if
you
have
an
api
span
and
then
you
start
trying
to
create
sdk
spans
as
children,
your
trace
is
going
to
be
broken.
F
C
Yeah
and
that's
an
interesting
point
that
did
not
come
up.
Nobody
mentioned
the
word
sampling,
so
I
haven't
really
thought
how
all
this
like,
how
either
context
approach
or
our
approach
kind
of
work.
With
that,
I
don't
know,
do
you
see
for
the
context
approach
is
sampling,
something
that
could
the.
F
The
context
approach
is
probably
fine
because
it's
actually
suppressing
the
creation,
at
least
as
I
understand
it,
it's
happening
at
the
instrumentation
level.
The
instrumentation
is
checking
to
see,
is
instrumentation,
enabled
and
or
like
is
it
suppressed?
I
guess,
and
if
it's
suppressed
it
doesn't
actually
try
to
create
a
span
which
means
that
your
apparent
span
well,
like
the
current
span,
stays
the
same.
F
F
So
the
context,
sorry,
the
suppress,
instrumentation
approach
is
probably
more
robust
or
certainly
more
robust
in
that
case
potentially
less
efficient,
but
I
don't
know:
you'd
have
to
benchmark
it
to
figure
it
out,
because
you're
doing
an
extra
thread.
Local
read.
F
C
Yeah,
so
that
was
really
kind
of
the
spec
said,
and
the
the
resolution
was
that
at
least
before
js
gas
they
wanted
to
kind
of
like
figure
this
out.
There
will
be
a
little
bit
of
spec
work
in
that
area.
I
think-
and
I
don't
know
if
we're
lucky
they'll
just
come
up
with
a
great
solution
that
we
can
just
implement
and.
F
Yeah,
I
kind
of
imagine
that
they
could
just
make
this
optional
effectively
having
the
equivalent
of
instrumentation
base
and
have
this
suppressed
instrumentation
sort
of
context
functionality
there.
I
don't
know
that
it
has
to
be
on
context
specifically
you're,
really
only
suppressing
instrumentation.
That
knows
about
it.
I
think,
unless
this
is
implicit
in
some
way
that
like,
if
you
have
suppressed
instrumentation,
that
you
just
won't
create
spans.
F
C
I
suspect
I
don't
know,
I
don't
have
to
look
at
this
implementation,
but
I
feel
like
it.
I
feel,
like
tracer,
tries
to
check
this
flag
to
figure
out
if
it
should
actually
start
a
span
or
not.
Don't
don't
hold
me
to
that,
but
I
suspect
that
might
be
how
it
works.
It
might
not
just
be
like
a
flag
that
everybody
is
checking.
I
think
I'm
gonna
try
to
like
push
it
down.
F
Yeah,
so
that's
really
a
spec
extension
and
so
yeah.
It's
a
valid
question.
Is
that
allowed
or
not,
like
we've,
been
moving
stuff
out
of
the
api
package
into
other
places
because
they're
not
part
of
the
spec.
C
Yeah,
I
don't
know,
should
we
continue
talking
about
this?
Should
we
possibly
move
on?
I
think
we
can
move
on,
so
I
was
expecting,
which
I
think
yeah.
I
think
everybody's
just
like
heads
down
trying
to
get
their
stuff
in
a
ga
able
or
soon
to
be
gable
or
1.0
state.
C
C
On
that
note,
it
doesn't
look
like
we
have
any
burning
questions
on
the
agenda.
Does
anybody
have
one
that
they've
been
secretly
holding
or
thought
of.
F
My
pr
is
lagging
a
little
bit.
I
want
to
make
a
joke
about.
I
need
to
find
time
to
work
on
it,
but
given
it's
about
time
now,
but
still
the
I
hope
to
get
that
done
tomorrow.
I've
got
a
bunch
of
meetings
this
afternoon
and
I
lost
a
couple
of
hours
to
os
updates
this
morning.
F
So
yeah
I
will
hopefully
get
the
initial
version
that
we
talked
about
last
week
done
tomorrow
and
I
think
that's
our
last
thing
unless
I'm
missing
something,
I
think
that's
the
last
thing
we
need
for
the
the
milestone.
F
All
right,
tracer
in
span
our
old
friend,
so
yeah
tracer,
inspan
yeah.
We
need
to
follow
up
on
that
discussion.
I
don't
know
whether
we
want
to
have
that
discussion
here
or
just
get
people
focused
on
the
github
discussion.
I
think
where
we
got
to
was:
let's
remove
the
explicit
parent
context,
argument
and
move
this
or
potentially
move
this
out
to
somewhere
else.
This
again
is
one
of
those
api
extensions.
So
is
it
permitted
by
the
spec
or
not.
C
Yeah,
so
if
we
moved
it,
would
we
move
it
to
like
the
the
utils
package
where
untraced
is?
Would
that
be.
F
We'd
move
it
to
a
utils
package.
I
don't
know
if
it's
that
utils
package
we'd
have
to
debate
that
a
little
bit.
I
think,
but
that's
like
the
place
that
exists
right
now
so
yeah.
We
could
do
that.
E
F
Yeah,
so
it's
a
good
question
right
should
it
be
in
a
separate
utils
package
that
is
optionally
brought
in
or
should
it
be
in
common
things
in
common
are
not
really
well,
I
mean
not
at
all
part
of
the
api
or
sdk
specs.
F
So
arguably
anything
there
is
fair
game
and
we
can
decide
how
how
much
support
we
want
to
provide
for
it.
But
the
other
argument
is
that
this
should
go
in
some
kind
of
convenience
package.
You
know
open
telemetry
convenience
or
something.
E
Yeah,
oh
open,
telemetry,
ruby
helpers
or
something
I
I
actually
don't
really
have
a
very
strong
opinion
on
it
other
than
that,
just
whatever
we
choose,
we
have
to
make
sure
we
message
it
well,
but
I
don't
really
actually,
whatever
makes
the
most
sense
to
other
people
is
fine
with
me.
I
also
don't
know
if
there's
much
point
in
rehashing
discussion
on
it
here,
because
I
don't
know
if
any
of
us
have
any
different
opinions
than
what
we
had
last
time.
I
don't.
F
C
I
guess
my
biggest
question
would
be
like
right
now.
This
is
used
a
lot
in
instrumentation
and
if
we
like
right
now,
it's
kind
of
actually
it's
buggy
in
anything.
That
kind
of
starts
your
first
span
in
process.
I
think
in
general,
like
we're
losing
the
baggage,
so
I
think
we've
run
into
this
in
a
handful
of
places,
but
anything
that's
like
further
down
in
the
trace.
It's
been
working,
fine,
I
think
so.
C
F
E
It's
a
very,
very
real
concern,
then
I
think
actually
that's
a
pretty
good
argument
for
putting
it
in
some
place,
like
utils
or
just
something
else
that
just
gets
pulled
in
a
lot
of
places.
C
All
right,
so
it
sounds
like
we're
thinking
about
putting
this
in
a
separate,
a
separate
gem,
a
separate
namespace.
So
I
think.
F
Yeah
I
mean
the
the
things
that
we
should
figure
out
on.
That
discussion
item
are
how
convenient
is
it
going
to
be
to
use
if
it's
not
on
the
tracer
itself?
F
So
if
this
becomes
something
where
you
have
to
do,
you
know
open
telemetry,
colon
colon
convenience,
colon
colon
with
span
or
in
span
and
then
pass
in
the
tracer
and
all
this
kind
of
stuff,
then
maybe
it's
not
that
convenient.
C
C
E
Yeah,
I
would
feel
weird
if
it
wasn't
on
tracer,
like
it's
one
of
those
things
where,
if
I
were
to
require
this
helper
package,
somehow
I
would
expect
it
actually
to
reopen
the
tracer
class
and
add
some
methods
to
it.
I
mean,
I
know
that's
kind
of
always
a
weird
feeling
when
code
does
that
but
like
I
would
expect
it
to
show
up
there
and
since
it's
ours,
you
know
we
can
monkey
patch
our
own
stuff
relatively
safely.
Ish.
G
I
don't
know
so
so
a
user,
maybe
a
new
user
coming
and
picking
up
open,
telemetry
ruby,
would
have
to
also
require
open,
telemetry
convenience
and
then
that
would
magically
monkey
patch
tracer
with
some
unspecced
behavior
sounds
about
right.
I
think.
G
E
E
Turns
out
there
was
no
easy
answer,
so
we
have
picked
this
one.
I
guess
you
know
I
actually
do
feel
like
starting
a
convenient
gem
could
be
useful.
You
know,
there's
the
talk
of
the
convenience
api
that
might
shake
out.
I
don't
know
if
we
have
other
things
for
it
yet
so
it
might
be
premature,
optimization
a
bit,
but
I
could
see
perhaps
that
being
a
place
where
we
experiment
with
other
ways
of
making
the
open,
telemetry
ruby
distribution
a
little
easier.
E
I
I
guess
I
just
don't
know
what
else
we
would
put
in
there.
Yet.
I
just
have
like
this
this,
like
nagging
feeling
that,
like
we
might
want
it
eventually
anyways.
F
F
Potentially,
I
think
the
argument
behind
the
convenience
api
is
that
this
management
of
tracers
is
kind
of
inconvenient
right
now,
and
it
would
be
nice
if
you
could
just
abstract
that
away.
Somehow,
like
you
implicitly
get
a
tracer
and
then
your
your
things
like
in
span
operate
on
this
implicit
tracer,
which
doesn't
work
as
well
in
auto
instrumentation,
where
you
do
want
a
separate
tracer
so,
but
I
may
be
reading
too
much
into
the
the
sig
or
whatever
it
is.
C
So
not
to
totally
derail
this,
but
I
think
I
mean
this
issue
about
instance.
This
was
the
one
with
some
controversial
arguments,
but
as
we
talk
about
this
we're
talking
about
it
well,
this
is
not
a
spect
method
and
I
know
we
have
withspan,
which,
with
span
is
allowed
with
span.
F
Is
allowed
okay,
yeah,
there's
a
there's
a
specific
bit
about
having
a
helper
that
sets
the
span
in
the
context
or
makes
the
span
current
in
the
context
for
a
block
or
something
so
that
that's
kind
of
a
an
optional
bit
in
the
spec,
so
yeah
with
span
is
fine
in
span
is
not
specced.
So.
D
So
I
just
I
feel
like
I
have
to
ask
this
question,
or
I
really
want
to
what
level
of
hand
slapping
do
we
face
if
we
leave
in
span
in
the
api,
because
talking
about
it
out
loud,
it
sounds
like
we're
potentially
doing
the
wrong
thing
to
adhere
to
the
spec.
F
Yeah
there's
a
a
part
of
that
and
that's
kind
of
what
the
js
sig
is
going
through
right
now
right,
that's
the
this
suppress
instrumentation
thing
is
not
part
of
the
spec,
but
it
is
part
of
their
implementation.
So
you
know,
are
we
allowed
to
add
that
kind
of
extension
to
the
api?
So
that's
what
the
debate
is,
I
guess.
F
Well,
we
can
either
wait
for
the
resolution
of
that
debate
or
we
can
preemptively
decide
that
you
know
what
we
just
want
to
move
forward
and
move
this
out
of
the
api,
or
we
can
place
a
bet
that,
oh
you
know
it's
going
to
be
allowed,
and
so
let's
leave
it
in
the
api.
But
then,
if
it's
like,
if
we're
on
the
wrong
side
of
that
bet,
then
we
have
issues
with
like
deprecating
part
of
our
supposedly
three-year
supported
thing.
D
Yeah
it
just
it
seems
like
moving
this
method
away
or
having
this
external
inconvenient
convenience
gem
it
like
it's.
Just
it's.
It's
hurting
adoption.
It's
going
to
hurt
people
who
want
to
use
this
to
make
this
more
complicated
for
us.
We
can
talk
about
it
and
reason
about
it
and
be
like
well,
it's
not
so
bad,
it's
not
so
bad
and
I
I
think,
like
ultimately
yeah.
It's
not
so
bad
when
you're
familiar
with
it,
but
if
you're
looking
to
get
started,
you
want
to
use
it
like
the
inspan
is
a
great
method.
It's.
F
Yeah,
so
I
mean
the
existence
of
the
convenience
sig
or
project
or
whatever
it
was
called
that
was
created
because
the
initial
feedback
was
this.
Api
is
kind
of
hard
to
use
at
first
glance,
so
you
know
for
80
of
use
cases,
it's
a
bunch
of
work
that
you
have
to
do
that
you
know,
should
be
abstracted
away
so
that
that
was
the
reason
that
convenience
project
was
set
up,
but
it
I
don't
know
that
it
fizzled
out
it's
just
there.
F
Wasn't
there
wasn't
enough
energy
to
hit
all
the
proposed
tracing
projects
at
the
same
time,
and
it
seems
like
this
is
the
one
that
lost
out.
I
don't
know
if
there's
been
any
update
from
ted.
F
You
know
in
the
last
few
weeks,
but
it
seems
like
the
convenience
api
was
just
put
on
the
backbone
for
a
bit.
C
So
I
kind
of
agree
with
with
what
you're
saying
there
about
just
moving
this
is.
It
would
make
us
that
compliant
but
it'll
be
probably
pretty
inconvenient
for
users,
and
it
feels
it
feels
not
great,
and
it
just
feels
it
feels
like.
We've
made
a
lot
of
concessions
in
open
telemetry,
I
think
over
its
history
to
kind
of
align
with
with
with
the
other
segs
and
just
kind
of
ways
of
doing
things
that
have
really
like
upped
the
complexity.
C
But
I
don't
know
we
all
get
used
to
them
all
the
time.
So,
but
I
I
know
like
it's,
it's
been
like
a
slow,
a
slow
boiling
over
over
the
course
of
the
project
where,
like
things
come
in
and
you're,
like
that's
the
craziest
thing,
I've
ever
heard
and
then
a
month
or
two
later
like
all
right.
That's
just
why
we
do
it
and-
and
you
move
on
with
your
life.
E
Yeah,
I
am,
I
think
I
actually,
I
agree
with
you
too
robert
it
it's
one
of
those
things
where,
like
I,
I
feel
conflicted
about
where
it
should
go,
because
it's
so
nice
and
like
I
actually
really
like
it.
I
think
like
if
I
were
to
to
to
make
the
decision,
not
that
I
am
in
charge,
of
course,
because
it's
not
my
project,
but
I
would
say
something
like
you
know.
The
in
span
method
itself
is
not
very
much
code.
E
Maintaining
it
over
the
course
of
a
1.0
release
is
probably
not
going
to
hurt
us
too
much.
I
mean
it
might,
who
knows,
but
like
it's
not
too
bad,
and
if
it
runs
into
problems
with
us
attaining
1.0
status,
we
do
at
least
have
some
ideas
on
how
we
could
move
it
and
how
we
could
resolve
that,
even
if
it's
not
optimal,
so
we
could
choose
to
execute
that
later.
E
To
me,
the
biggest
problem
with
it
is
just
that
the
arguments
are
confusing
and
it's
it's.
It
has
that
weird
corner
case
to
me.
If
we
fixed
that
it
feels
defensible
to
leave
it
in
and
then
if
we
get
a
lot
of
pushback
from
other
people,
we
can
always
change
direction
later
with
you
know
not
not
be
too
hard.
On
our
end,
that's
kind
of,
I
guess
my
synthesized
thoughts
at
this
point.
F
Yeah
yeah,
the
the
like
the
balance,
is
just
like
what,
if
we
cut
a
1.0
with
this
in,
we
need
to
support
it
forever,
if
the
not
forever
three
years
right,
which
is
kind
of
forever.
If
the
convenience
api
comes
along
and
is
significantly
different,
and
we
can't
kind
of
argue
that
oh
we're
kind
of
spec
compliant
with
the
convenience
api,
because
this
thing
kind
of
looks
like
that.
F
Other
thing
that
you
expect
over
there,
then
you
end
up
with
like
more
than
one
way
to
do
it,
which
we're
not.
H
C
F
G
So
here's
a
in
span
is
simple
and
convenient,
so
we
could
leave
it
in
our
sdk
at
a
point
where
the
convenience
spec
says:
here's
the
way
to
do
scopy's
fans
the
what
the
behavior
that
we
get
with
and
we
make
like
a
convenience
gem.
We
can
implement
it
correctly
there
and
then
deprecate
this
method,
and
then
users
get
a
deprecation
warning
until
for
three
years,
when
they're
using
the
wrong
one.
E
E
E
H
F
C
Yeah,
I
think
it
would
be
nice
to
just
kind
of
have
a
comment
where
you
capture
some
of
these
things
and
then
just
kind
of
like
pseudo
code
out
or
actually
like,
write
out
the
the
code
of
what
the
replacement
would
look
like.
I
did
pull
up
this
python,
the
python
repo
really
quick,
because
I
feel
like
their
start
as
current
span
is
the
same
as
our
inspan.
C
G
H
E
E
But
the
behavior
but
there's
another
group-
that's
doing
it
in
a
very
similar
way.
So
that's
nice.
F
C
Yeah
so
so
I
don't
know
if
this
is
a
a
can
of
worms
or
not,
but
it
I
I
thought.
Maybe
this
could.
If
we
do
decide
to
go
forward
and
just
say
you
know
what
we're
going
to
go
with
the
president
yeah
with
within
stan
and
we're
going
to
go
with
the
arguments
that
we
are
pretty
sure
are
just
going
to
be
like
uncontroversial,
and
then
we
can,
you
know,
as
the
convenience
spec
comes
around
it's
like.
We
know
something
like
this
method
is
going
to
exist
and
we
can.
C
We
can
adjust
the
name
and
add
additional
arguments
later,
just
it's
impossible
to
predict
exactly
what
arguments
and
behavior
will
be
specked,
but
if
we
keep
it
like
pretty
pretty
lean
to
start
with,
like
there's
a
good
chance
that
it'll
work
out,
but
I
don't
know
it's
food
for
thought,
I
think
yep.
D
So
I'm
just
gonna
lean
in
and
say
that
I'm
strongly
in
favor
of
keeping
it
just
because
I
feel
like
I
don't
I
either
don't
understand
the
implications
of
like
us
kind
of
breaking
the
spec.
I
don't
know
like
what
that
actually
looks
like
and
how
much
trouble
it
causes
for
us,
but
I
think
for
me,
I'm
thinking
the
perspective
of
we
want
people
to
start
using
this.
We
want
more
adoption.
We
want
people
to
like
this
right,
like
especially
like
from
my
perspective
at
shopify.
As
that
migrating
application
is
over.
D
F
Sorry,
I
I
don't
want
to
cut
you
off,
but
the
I
I
kind
of
do
so.
The
is
my
co-worker.
So
I'm
allowed
to
do
that.
F
Sorry,
there's
a
thing
in
the
spec
which
is
worth
staring
at
a
little
bit.
I
think
it's
acceptable
to
have
it
in
there.
The
language
says
in
languages
with
implicit
context,
propagation,
which
is
us
spam
creation
must
not
set.
The
newly
created
span
is
the
active
span
in
the
current
context
by
default,
but
this
functionality
may
be
offered
additionally
as
a
separate
operation,
so
it
is
permitted.
F
I
do
think
we
should
get
rid
of
the
the
explicit
parent
context
option
and
then
just
leave
it
where
it
is
and
if
we're
all
happy
with
in
span
as
a
name,
I
think
that's
fine
and
we
can
just
move
ahead
with
it.
So
so.
E
That's
actually
pretty
significant,
though
I
didn't
realize
that
the
spec
had
a
carve
out
for
allowing
a
convenience
method
like
this,
so
like
creating
a
new
span,
calling
the
initializer
and
a
span.
Obviously
shouldn't
set
it
to
the
global
context,
and
that
makes
sense
I
I
didn't
know.
Actually
there
was
a
carve
out
for
like,
but
if
you
have
one
of
those
fancy
you
know
squishy
languages
that
can
do
this
type
of
stuff.
Here's.
E
F
F
So
we've
got
in
span.
I
think
it's
okay,
so
yeah
I'll
write
up
that
conclusion.
Then,
on
the
discussion
point
to
the
spec
thing
and
let's
just
get
rid
of
the
explicit
context
or
explicit
parent
context,
option
and
move
on.
C
A
F
I
guess
just
a
quick
update:
we
did
the
zero
seventeen
zero
release.
We've
had,
I
think,
a
couple
more
prs
in
since
then.
We
may
want
to
do
some
of
those,
I
think
add
new
instrumentation.
I'm
just
going
to
sorry.
Sorry.
E
F
Yeah
sorry,
you've
had
the
instrumentation
yeah.
Sorry.
I
knew
I
had
to
prove
a
couple
of
things.
So,
oh,
okay,
so
we
released
yours
right,
the
the
postcards
one,
I
think,
did
we
release
the
koala
one
or
the
koala
one's
about
to
go
in.
F
Okay,
so
I'm
going
to
hit
merge
on
that
one
that
one's
ready
to
go,
so
we
probably
want
to
release
this
as
well
get
you
know
another
one
release
of
the
instrumentation
all
and
of
this
koala
instrumentation.
F
F
Sorry,
robert
robert
has
we
we
rolled
out
open,
telemetry,
ruby
to
a
high
volume
application
this
morning
or
because
robert
did
he's
the
one
who
actually
works,
and
they
just
tell
them
what
to
do
so.
F
D
Yeah
they
like
it's
a
it's
a
regression
realistically,
so
what's
interesting,
and
what
how
this
person
was
using,
the
sql
act
record
notifications
spans
is
there
he
was
actually
tracking
down
n,
plus
one
queries
using
it.
So
he
could
see
that
and
you
could
see
like.
Oh
I
have
this
this
operation
here,
that's
doing
an
n
plus
one,
so
he
was
using
that.
So
he
took
one
of
the
our
previously
instrumented
staff
that
we
opened
palm
tree.
One
you
put
them
side
by
side.
He
said
you
know
like
this
is
wrong.
D
I
can't
do
the
same
things,
so
we
do
need
to
investigate
how
we
handle
that
for
context
that
we
completely
redact
the
db
statement.
We
don't
just
obfuscate
it.
We
completely
blow
it
away.
So
there's
a
lot
of
potential
information
lost
there.
I
haven't
like
actually
talked
about
what
we're
gonna
do
to
go
forward
and
fix
it,
but
like
it's
a
big
concern
for
them
because
of
how
valuable
they
found
it
so,
but
they
did
look
at
the
active
record
kind
of
the
proposed
instrumentation.
D
They
said
it
looks
good,
and
I
just
I
don't
know
if
that
actually
substitutes
or
addresses
that
regression.
So
I
don't
know
the
the
other
thing
that
we've
noticed,
and
I
don't
know
if
anybody
else
who's
kind
of
deployed,
open,
telemetry's
notices
with
the
reddest
instrumentation.
If
you're
using
like
sidekick,
you
get
a
lot
of
orphans
fans
just
kicking
around
in
the
background
and
that's
one
of
the
that's
actually.
D
So
those
are
the
kind
of
the
two
pieces
of
feedback
and,
like
I
said,
I'm
not
100
sure
how
we
should
address
either
because
I
think
completely
squelching
say
like
redis
fans
that
don't
have
parents,
not
the
worst
thing,
that's
what
we
were
doing
previously
but
could
potentially
lose
out
on
some
valuable
information
that
is
now
just
being
silenced
and
then
for
the
active
record
stuff.
I
I
need
to
spend
a
bit
more
time
on
that
pull
request
and
see.
D
F
F
Br
pop,
or
was
it
be,
a
pop
l,
push,
I
think,
if
you're
using
the
psychic
enterprise
or
something.
H
F
The
the
thing
is,
you
need
to
add
some
kind
of
tracing
around
the
worker
loop
in
order
to
deal
with
this,
and
we
do
that
in
some
cases
at
shopify,
but
yeah.
It's
something
we
need
to
solve
in
the
sidekick.
Instrumentation
really.
D
Does
actually
have
a
lot
of
it
like
it
is
way
noisier
by
default,
as
if
you
look
at,
if
you
don't
look
at
right
now,
there's
some
psychic
instrumentation
patches
that
I've
added
the
default
behavior
is
to
silence
like
the
worker
loop.
So
it
does
cover
a
lot
of
these
reference
fans,
but
it
doesn't
cover
all
of
them
like
I
just
spent
probably
like
four
days
hunting
down
most
of
them,
but
there's
still
a
couple
that
elude
me
and
it
often
they
can
come
from
supplementary
sidekick.
D
F
Yeah,
I
was
going
to
say
for
the
active
record
stuff,
if
you
know
ultimately,
if
we
can't
find
a
path
forward
that
doesn't
use
active
support
notifications,
then
we
may
just
have
to
bite
the
bullet
and
use
active
support
notifications
because
yeah,
as
as
robert
said
at
shopify,
it
is
a
regression
compared
with
our
previous
tracing
library
and
that
used
active
support
notifications.
It
just
it
had
a
whole
lot
of
code
to
try
to
protect
itself
from
all
the
corner
cases
that
you
can
get
with
asm.
F
E
The
main
problem
with
the
active
support
or
the
active
record
pr
as
it
is,
is
just
that,
like
certain
certain
apps
load
rails
in
a
way
that's
different
than
yours
and
and
then
patches
don't
get
applied
in
the
right
places
and
things,
and
I'm
wondering,
is
there
some
general
solution
to
that
that
we're
missing
out
on
you
know,
there's
lots
of
things
that
actually
end
up
monkey
patching
rails,
and
I
don't
actually
hear
about
this
problem
that
often
with
them.
E
You
know
it,
it's
not
that
it
wasn't
completely
like
foreign
there's,
a
reason
we
thought
about
it
and
we're
like
oh
yeah.
Of
course
that's
what's
happening
but
like
it
does
kind
of
seem
like
this
works
more
or
less.
Nowadays,
you
can
kind
of
do
this.
I'm
wondering,
if
is
there
some
way
that
like
should
we
run
this
as
a
rail
tie
like
the
active
record
like
in
in
that
way,
we
can
control
when
it
gets
loaded,
and
how
like
is
that
the
type
of
approach,
maybe
that
might
work
better.
D
So
that's
that's
actually
what
we
do
internally,
like
our
wrapper
gem
loads
and
applies
all
the
instrumentation
patches
as
part
of
a
rail
tie,
and
I
thought
that's
why
initially
I
hadn't
seen
this
issue,
but
I
did
move
it.
I
tested
it
against
another
app
and
sure
enough.
I
was
facing
the
same
issue.
I
tried
kind
of
pushing
it
earlier
in
the
initialization,
but
I
don't
know
if
I
didn't
spend
a
ton
of
time
there
and
I
think
maybe
there's
still
some
room
to
get
that
working.
D
I
think
eric
mentioned
that
last
time
this
came
up.
He
said:
try
like
hitting
an
earlier
initialization
hook,
or
something
like
that.
So
I
haven't
exhausted
that
investigation.
So
that's
when
I
go
back
to
it.
That's
what
I
intend
to
do.
I'm
hoping
I
find
the
solution
there,
but
as
a
just
a
regular,
you
know
in
your
config
initializers
there.
I
don't
think
this
is
even
close
to
be
considered
reliable,
patching
so
yeah.
B
Yeah,
I
don't
know
if
my
suggestion
from
last
week
would
help
the
thing
at
the
hook
I
was
thinking
of,
is
you
can
run.
You
can
have
a
rail
tie
that
runs
before
all
your
config
slash
initializers,
but
that
probably
doesn't
help
active
record
because
that
I
would
assume
gets
run
before
that,
but
it's
good
for
like
third-party
stuff.
E
Though
so
it
sounds
like
if
there
is
a
solution
to
be
discovered
for
active
record,
then
we
probably
don't
have
to
deal
with
notifications
and
thinking
at
a
bigger
picture
level
about
how
to
do
real
stuff.
If
we
can't
find
a
good
solution,
then
then
we
have
to
unfortunately
start
to
deal
with
that
problem.
E
That
makes
sense,
at
least
for
me,
that
gives
me
direction
on
any
other
pr's
I
throw
over
the
wall
for
random
bits
of
rails,
because
at
least
you
know
we
don't
intend
on
dealing
with
notifications
yet
so
I
can
continue
to
follow
the
patching
and
monkey
patching
sort
of
approach
which
works
for
me.
If
anyone.
D
E
Yeah
I
keep
turning
it
over
in
my
head,
like
they.
I
keep
recalling
like
some
some
comments
in
the
rails
code
base
about
like
how
you
can
add
any
sort
of
like
fan
out
q
system,
and
you
can
build
your
own
and
I'm
like
it
all
sounds
like
a
fun
thing
to
try
that
nobody's
actually
ever
done
and
and
it
yeah
just
feels
like
a
mess,
a
fun
mess,
maybe
but
sorry
I'm
just
battling.
I
don't
have
anything
useful
to
share
at
this
point.
B
I
did
want
to
circle
back
real
quickly
to
the
sql
redaction
bit.
That
seems
like
an
unsolved
problem
in
open,
telemetry
general,
because
not
because
of
anything,
but
I
think
it's
exacerbated
a
little
bit
because
of
the
split
between
whether
what
the
happy
path
is
around
your
tracing
pipeline.
B
F
This
room's
use
case
there
right.
We
have
the
option,
at
least
for
my
sequel
and
I
think,
for
postgres,
as
well
of
the
obfuscation
using
the
code
from
new
relic
right
right,
so
yeah.
We
we
have
some
of
that
capability.
B
Like
pinged
microwave
and
respond,
I
just
mean
if
you're
the
end
user
you
were
working
with
robert
was
complaining.
Is
it
just
that
you
haven't
enabled
that
bit
yet.
F
Well,
so
the
the
problem
is
actually
that
our
our
tracing
pipeline
has
the
open,
telemetry
collector,
and
we
have
this
redaction
thing
in
it.
We
kind
of
because
we
don't
have
the
obfuscation
support
in
our
internal
gem.
So
we
just
need
to
do
this
thing
where
we
turn
off
the
red
action
when
we're
doing
the
obfuscation
gotcha,
and
we
probably
need
to
turn
on
the
obfuscation.
I
can't
remember
if
that's
set
by
default
for
us
yeah.
B
F
Nope,
okay,
we
can
I,
I
guess,
I'm
matt
and
I
have
been
talking
behind
the
scenes
about
whether
we
want
additional
approvers.
So
if
you
are
interested
in
becoming
an
approver
have
a
chat
with
us,
we
may
reach
out
to
a
couple
of
people
as
well,
or
we
will
reach
out
to
a
couple
of
people
as
well,
but
yeah
the
there's
certainly
been
an
increase
in
participation
in
the
the
sig
and
the
project.
So
yeah.
B
B
F
Cool
yeah:
if
there's
nothing
else,
we
can
get
three
minutes
back.
I
guess
all.