►
From YouTube: 2022-04-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).
A
D
A
Well,
well,
it
is
the
usual
starting
time
so
I'll
go
ahead
and
share
my
screen.
Try
to
go
through
the
spec
sig,
try
to
keep
it
to
like
10
minutes
ish
and
then
bring
it
back
to
the
see
hotel,
ruby
repo
and
go
from
there.
Does
that
sound
like
a
decent
plan.
A
I
do
a
little
bit
of
work
in
the
js
seg
and
we
also
try
to
ingest
otop
json
that
lights
up
and
it
has
been
unstable
and
painful.
So
it's
a
conversation.
We've
had
in
the
specs
say
here
and
there
about
making
otopjs
unstable
and
I
think,
there's
a
reluctance
to
make
it
stable.
Just
because
there's
a
lot
of
things
that
you
can
change
in
the
binary
protobufs
that
will
remain
backwards
compatible.
A
That
will
not
that
you
would
not
be
able
to
do
to
chase
on.
So
you
kind
of
have
to
have
a
really
good
idea
that
things
are
not
going
to
change.
People
were
pretty
receptive
that
now
is
a
much
better
time
to
start
talking
about
that.
So
I
don't
really
know
that
it
will
impact
this
thing
very
much,
but
if
anybody
has
been
waiting
for
for
json
as
as
an
option,
this
could
be
relevant.
A
So
apparently
the
spec
has
this
option
that
I
I
know
we
talked
about
a
long
long
time
ago
in
this
seg,
when
some
of
the
initial
http
kind
of
framework
instrumentation
was
happening
about
collecting
headers.
But
I
don't
think
we
have
support
for
this,
but
basically
you
can
provide
in,
I
think,
python
and
java.
You
can
provide
like
a
list
of
headers
that
you
want
to
extract
out
of
a
request
or
or
response
and
add
to
a
span.
I
think
so.
A
This
was
kind
of
specifying
environment
variables
to
configure
that
there
are
some
debates
about
like
the
format
of
of
the
headers,
but-
and
there
are
also
some
debates
about
whether
or
not
this
belongs
in
the
spec,
given
that
it's.
A
Not
something
implemented
by
all
languages,
but
I
think
the
fact
that
it
is
actually
specified
as
being
an
optional
feature.
I
think
that
smooths
over
that
part
of
the
argument-
and
I
think
the
last
part
of
the
argument
was
mainly
what
daniel
dailer
was
saying-
that
really
the
header
name
should
just
follow
the
rfc
for
header
names
and
nothing
special
should
be
happening
in
in
the
list.
I
think
there
was
some
special
like
translation
that
was
happening
that
was
kind
of
very
like
python,
influenced.
A
Any
or
comments
about
this
one
at
this
point.
D
So
it's
basically
http
instrumentations
a
way
to
configure
http
instrumentations
to
capture
some,
but
not
all
headers
of
incoming
requests
is
that.
A
Yes,
so
this
particular
pr
wasn't
about
about
the
collection
of
the
headers.
It
was
about
how
to
structure
the
environment
variables
to
collect
those
headers.
But
I
guess
like
the
discovery
for
me,
is
that
the
spec
has
like
an
optional
has.
Has
this
as
an
optional
feature
that
that
you
can
have
in
your
http
instrumentation?
A
I
know
way
way
back
when
we
first
had
our
you
know:
rack
sinatra:
rails
instrumentation.
I
think
these
were
discussions
that
we
kind
of
had
because
datadog
had
the
ability
to
kind
of
collect
these
things,
and
a
lot
of
the
instrumentation
was
loosely
based
off
of
those,
but
I
think.
A
A
A
D
Something
I've
got
a
tickle,
but
maybe
it
was
added
as
a
as
a
configuration
item
that
you
could
give
in
the
configure
block
the
like,
config.use
all
and
then
the
hash
that
you
could
throw
in
there.
You
could
say
which,
but
maybe
it's
not
exposed
as
an
environment
variable,
but
it's
been
a
while.
Since
I
looked
at
that.
A
Yeah,
if,
if
anybody
wants
to
chime
in
feel
free
to,
I
will
start
moving
on
here
for
now
this
seems
somewhat
relevant
and
it's
the
http
spec.
I
think
this
is
the
one
that
has
been
kind
of
incubating
in
the
instrumentation
seg,
but
it's
now
there's
like
a
draft
here
and
it's.
A
I
think
lumilo
was
looking
for
feedback
and
some
of
the
feedback
that
people
were
already
providing
was
like.
It
changes
a
lot
of
what
is
already
existing
for
http
semantic
conventions,
which
would
cascade
to
a
lot
of
changes
in
the
various
cigs.
A
A
It's
probably
worth
a
look,
and
if,
if
we
have
opinions
as
to
whether
this
is
on
on
the
right
track
or
not,
we
should
probably
speak
up
because
it's
if
it
does
get
integrated,
we
will
kind
of
have
to
adopt.
What's
here.
A
It
seems
like
I
think
daniel
was
trying
to
do
some
refactoring
of
some
exporters
in
the
js
world
and
was
having
trouble
actually
understanding
what
the
spec
was
asking
for
for
like
grpc
defaults.
If
you
provide
nothing
and
it
seemed
like.
D
Up
so
yeah,
it's
an
interesting
default
for
the
sdk
or
or
client,
but
it
means
that
you're
not
running
the
default
listener.
You've
done
something
not
default
to
get
something
on
localhost
4317.
A
There's
kind
of
a
quick
tour
of
some
of
the
open
metrics
issues.
A
There's
this
view
conflicts
issue
like
what
to
do
when
conflicting
views
are
registered
and
I
think
really
there's
a
handful
of
options,
but
the
popular
options
are,
if
you
can
detect
this
at
startup
time
like
you
could
fail
fast.
If
you
wanted
to,
I
think
that
that
behavior
does
tend
to
scare
a
lot
of
people,
and
another
option
is
just
to.
A
Detect
the
situation
and
still
send
data
to
these
views
and
then
just
log
that
there
is
a
is
a
conflict
and
the
users
can't
kind
of
figure
that
out
without
crashing.
A
A
So
I
know
that
the
spec
has
had
some
updates
around
registering
callbacks
more
recently
kind
of
some
later
features,
but
I
think
what
this
is
doing
is
it's
adding.
A
An
additional
way
to
define
these
callbacks
and
I
think
it
largely
comes
from
the
the
goling
take
on
on
what
would
be
the
most
idiomatic
way
to
kind
of
use
this
feature,
but
somebody
from
the
javasci
also
spoke
up
saying
that
they
would
like
this.
I
think
I
think
there
was
some
question
about
whether
yeah
about.
A
I'm
not
sure,
I'm
not
sure
if
we're
actually
this
far
along
yet
or
not
robert,
but
I
guess
when,
when
we
start
looking
at
the
the
callback
apis
and
implementation,
this
could
be
relevant.
A
C
A
Thank
you,
I'm
not
seeing
any
issues
or
prs
or
burning
questions
linked,
but
does
anybody
have
any
anything
on
their
mind.
B
I
think
I
think
ariel
flagged
a
pr
and
the
slack
for
us
to
look
at
it's
the
same
one
we
discussed
last
week.
I
don't
know
if
it's
I
don't
know,
maybe
let's
just
go,
give
it
a
look
right
now,
because,
yes,
this
too,
I
think
that's
worth
doing.
E
Looks
like
he's
the
context
is
registry
is
part
of
the
base
instrumentation,
but
is
used
by
the
sdk.
So
by
creating
a
separate
gem
for
the
registry,
we
can
decouple.
Well,
I'm
not
sure
the.
I
guess
I
I'm
not
sure.
If
he
he
wants
to
have
registry
live
and
core
it
sounds
like,
and
that
way
we
can
move
base
into
contrib
without
forcing
sdk
to
rely
on
base
anymore.
B
But
there's
actually
really
only
two
files
in
the
base
that
interact,
and
so
one
of
them
is
the
registry,
and
one
of
them
is
the
base
that
inherits
that
all
the
instrumentation
inherits
from
and
one
of
the
things
that
bass
does.
Is
it
on
an
on
inherit
the
inheritance
hook,
it'll
register
itself
with
the
registry,
so
the
sdk
doesn't
actually
need
to
know
anything
about
the
base,
but
all
the
instrumentation
classes
definitely
do,
but
we
do
need
to
keep
the
registry
so.
C
E
It
sounds,
I
guess
it
seems
fine
to
me
to
love
its
own
gem.
That
seems
like
a
non-controversial
way
or,
alternatively,
I'm
not
sure
why
it
can't
just
be
part
of
the
sdk.
I
guess
it's
offspec
of
the
sdk
right,
so
you
know
I
don't
have
strong
opinions.
I
haven't
reviewed
this
pr
outside
of
literally
just
reading
it
in
the
context
we
talked
about,
but
the
approach
seems
reasonable
to
me.
B
B
E
B
It
can
from
like
the
the
main
repo,
because
it'll
it'll
look,
so
instrumentation
cannot
depend
on
the
sdk
just
like
full
stop,
but
it
should
depend
on
the
api,
the
idea
and
like
we're,
we're
navigating
through
sort
of
like
undefined
unspec
territory.
Is
that
like
there's,
no
like
spec
for
auto
instrumentation
registering
itself
so
that
it
gets
configured
properly
right?
So
if
you
decide
that
you
want
to
implement
your
own
open,
telemetry
sdk
so
long
as
it's
api
like
it
uses
the
same
api
and
it's
compliant
in
that
regard.
There's
no
reason.
B
You
should
not
be
able
to
use
any
of
the
audio
and
auto
instrumentation.
So
we
have
to
make
sure
that
the
that
the
instrumentation
remains
decoupled
from
the
sdk
and
what
we've
kind
of
taken
the
liberty
of
doing
so
here
is
saying
that
we
have
this
registry
class
and
so
that,
if
you
implement
your
own
sdk,
you
can
use
this
registry
class
to
tell
all
of
the
instrumentation
to
install
themselves.
E
Cool
yeah,
it
seems
I
guess
it
would
seem
fine
to
me
to
keep
base
in.
You
know
the
regular
repo,
not
part
of
the
sdk
and
then
have
instrument.
You
know,
instrumentations
that
we
haven't
contribute
just
it's
a
convenience,
essentially
it
just,
and
they
could
just
point
to
that
gem
or
whatever
in
core
doesn't
seem
to
disagreeable
to
me.
I'm
not
sure
if
I'm
not
missing
something,
it
might
be
a
little
weird
to
have
like
one
random
instrumentationy
thing
like
instrumentation
folder,
with
just
bass
in
there.
E
But
not
I
don't
think
that's
a
big
deal
or
we
could
have
it
live
whatever
the
folder
structure
could
change
slightly
yeah.
I
don't
have
strong
opinions.
I
just
except
that
kernel
is
spelled
wrong,
so
yeah
everything
everything
else
seems
fine
to
me.
I
don't
know
it's
more,
just
like:
what's
what
do
people
want
to
maintain?
Is
there
some
I'm
trying
to
think
it's
like?
E
Well,
it's
just
easier
long
term
for
like
releasing
maintaining
stuff.
I
guess
I
do.
We
don't
need
to
think
about
it
live,
but
we
should
probably
just
give
arielle
clear
direction
either
way,
so
he
doesn't
have
to
spin
his
wheels
or
whatever
yeah.
Okay,
I
can
see.
I
have
to
do
a
few
things
after
this
evening.
I
can
reply
to
here
and
just
say,
like
cool
any
reasons
why
you
wouldn't
be
opposed
to
like
before
he
moves
without
a
draft.
E
You
know
here's
the
alternative.
What
would
you
prefer?
It's
kind
of.
I
don't
know
in
my
mind,
it's
a
little
bit
of
preference,
but
I
think
it's
nice
to
have
bass
stay
in
court,
so
people
at
least
like
know
what
to
they
could
still
maybe
use
that
jam.
If
and
if
they
don't
want
to
use
anything,
you
can
trib.
E
B
E
B
I
had
another
pr
that
I'd
like
to
just
kind
of
like
not
throwing
myself
under
the
bus,
but
maybe
throwing
myself
into
fire
here,
because
I
really
don't
want
it
to
seem
like
I'm
just
being
pushy
and
imposing
my
views
more
than
I
regularly
do
so.
Sam
at
this
pr
here
has
had
it
still
exists.
B
But
the
idea
is
that
we're
he's
working
on
some
instrumentation
internal
and
he's
trying
to
migrate
some
priority
instrumentation
to
the
open
source
stuff
on
this,
like
snowflakey
app,
and
so
one
of
the
things
that
we
want
to
be
able
to
do
in
the
same
way
that
we
have
the
ability
to
enrich
http
spans
through
the
the
client
context
or
with
retis.
We
could
do
the
same
thing.
B
You
can
say
like
redis
with
redis
attributes,
and
then
your
redis
span
will
enrich
itself
further
down
the
call
chain,
with
whatever
you've
specified
the
context
and
the
work
he
did
is
like
correct
and
it
works,
and
it's
the
right
way
to
do
it.
But
I
had
a
conversation
with
him
and
just
in
private,
because
he
just
asked
me
what
I
thought
about
it
and
I
shared
candidly
and
I've
kind
of
tidied
it
up
a
little
bit
and
copied
it
and
pasted
it
back
on
the
pr
for
everyone
to
see.
B
I
have
a
really
high
tolerance
for
duplicated
code
until
it
turns
together.
So
my
my
main
feedback
was
here
is
like
like
are
we?
Why
are
we
drying
this
up
like?
Because
it's
in
three
places
now-
and
I
guess
I
wanna-
try
to
articulate
it
as
best
as
I
can.
I
find
it.
B
This
is
kind
of
a
tricky
one
in
general,
my
tripwire
for
like
when
you
should
deduplicate
code
is
when
you
have
it
in
two
places
and
they've
proven
that
they're
the
same
and
usually
the
way
you
know
that
is
is
like
say
you
have
a
method
or
something
like
that.
A
similar
functioning
piece
of
code
in
three
different
places
and
they're
used
by
three
distinct
things
like
I
consider
each
instrumentation
package
sort
of
distinct,
if
not
like.
B
Obviously,
there's
commonalities
there
right,
but
they
are
their
own
packages,
so
we
have
it
in
the
common
for
client
contacts
and
then
we
have
it
directly
into
redis.
We
haven't
had
to
fix
a
bug
or
make
any
changes
there.
So,
like
these
things
haven't
churned
together
in
any
capacity.
So
I
don't
have
any
confidence
for
or
against
that.
B
These
are
exactly
the
same
pieces
of
code,
even
though
they
are
duplicates
of
each
other
right
like
they
aren't
necessarily
the
same,
and
you
could
very
well
make
probably
a
good
argument
saying
that,
well,
I
know
they're
like
identical.
They
are
the
same,
but
I
I've
been
in
this
situation
enough
times
where
they
look
the
same
and
they
behave
the
same
and
then
one
of
them
deviates
and
the
other
doesn't.
B
And
then
you
now
have
awkward
code
in
one
place
being
used
by
a
bunch
of
different
things,
and
I've
encountered
that
enough
times
that
I
am
avoidant
of
deduplicating
code.
That's
in
like
a
handful
of
places
like
if
this
wasn't
like
adding
to
the
fifth
place,
I
would
kind
of
concede
and
just
be
like
this-
isn't
the
hill
to
die
on
and
cool.
Let's
do
it,
but
now
that
it's
like
it's
the
third
one,
I'm
still
kind
of
my
feet
are
stuck
where
I'm
like.
B
I
think
it's
too
soon
rob's
pointing
so
we'll
allow
rob
to
speak.
D
Well,
it's
just
a
like
a
hook
in
when
you
are
yeah.
Okay,
go
ahead!
I
in
experiments
with
baggage,
like
the
the
I
want
to
add,
and
maybe
retrieve
things
from
a
named
key
in
the
context,
is
like
it's.
It's
in
these
two
instrumentations,
maybe
a
potential
third
that
was
being
added.
D
It's
also
kind
of
like
the
thing
that
underlies
baggage
there's
a
baggage
api
for
adding
things
to
baggage,
but
under
the
hood
it
could
use
this,
and
I
also
built
something.
You
saw
the
weird
experiment
that
I
called
carry-on.
D
That
was
baggage,
it's
not
baggage,
it
just
stays
within
the
process
which,
depending
on
your
back
end,
you
sometimes
want
to
be
able
to
duplicate
a
field
on
multiple
child
spans
because
you
get
you
know
a
user
id
at
a
parent,
but
you
can
associate
it
with
some
child
spam
later,
it's
handy
to
have
it
on
there,
and
so,
like
that's
four
and
maybe
five.
If
we
were
to
like
just
swap
out
what
baggage
uses
to
put
things
on
and
off
the
context
and
now
there's
a
reusable
thing.
D
That's
I
need
to
jam
some
stuff
on
a
lot
of
context,
but
in
a
sort
of
reliable
tested
way.
B
But
but
beyond
that
like
so,
if
you
so
this
pr
gets
merged,
we
now
have
this
extracted
piece
of
code
that
we
can
reuse
and
we
want
to
use
it
on
lmdb
or
something
I'm
just
picking
like
an
arbitrary
thing.
So
you
you
extend
it,
you
add
it
in
there
you're
not
done
it
does
that's
like
that's,
not
the
end
of
the
story
right.
You
now
have
to
go
into
the
actual
instrumentation
and
anywhere
that
attributes
are
being
generated.
You
now
need
to
merge
in
those
attributes
on
the
span.
B
So,
like
that's
only
half
of
the
story
right
now
that
you've
created
this
context
to
capture
the
information
you
actually
have
to
make
sure
the
instrumentation
everywhere
itself
respects
it
and
when
it's
generating
its
span,
it's
merging
in
the
client
context
or
the
lmdb
context,
attributes
right.
So
that's
one
thing
so
like
that's.
Why
I
think
it's
not
as
straightforward
as
just
like
extracting
it,
because
you
also
have
to
do
the
other
part.
B
So,
like
maybe
that's
a
weak
argument,
but
it
is
one
of
the
arguments
that
it's
like,
not
that
trivial
of
an
extraction
just
yet
and
then
the
second
part
is
it
becomes
like
in
my
comment
in
the
pr.
Maybe
I
can
elaborate
a
little
a
little
bit
further.
Is
that
like
becomes
a
little
bit
muddled
right
so,
like
you
have
client
context
right
that
we
use
in
common,
and
it's
this
thing-
that's
just
like
generally
available
for
people
to
use
and
like
we,
I
think
we
haven't
missed
any
spots.
B
We've
done
a
good
job
of
making
sure
that
all
of
our
http
instrumentation
libraries
that
we
have
in
this
repo
will
merge
in
that
http
client
context,
attributes
right.
So,
like
again,
that's
the
more
manual
part
where
and
all
these
instrumentation
classes
are
like
we're
merging
this
thing
in
so,
if
you
use
http
client
context
with
attributes,
you
know
it'll
show
up
on
your
hdb
spam.
It's
like
great.
We
did
the
legwork.
B
So
someone
now
follows
up
and
says
like
I,
for
whatever
reason
want
to
add
like
net
http
client
contact.
So
now
this
is
not
just
client
context.
There's
like
one
scope
to
net
http,
so
I
guess
a
do.
We
intend
to
support
that
because
now
it's
really
easy
to
do
that
right.
All
you
have
to
do
is
slap
in
one
extend
and
then
the
expectation
is
that
it'll
work
and
then,
but
you
also
again
have
to
go
and
now
you're
emerging
client
context
and
net
http
and
then
which
one
gets
precedent.
B
So
we
have
to
decide
that
we
also
have
to
do
so.
You
know
you're
merging
multiple
contacts
in
together.
Right
again,
that's
assuming
we're
like
yeah.
Let's
just
do
that.
So
I
think
that,
like
that's,
what
makes
this
a
little
bit
less
clear
to
me,
I
haven't
like
totally
jumped
into
what
you
were
saying
with
the
carry-on
I
had
to
like
reopen
how
you
did
that
because
I
think
did
you
use
a
span?
Processor
yeah.
B
I
think
the
spam
processor
approach.
Isn't
it
somewhat
disconnected
from
this
work?
Yes,
because,
like
that
approach.
D
B
A
lot
of
sense
to
me:
we
did
something
similar
internally,
we
didn't
call
it
carry-on,
it
wasn't
as
fun
as
yours.
It
was
very
like
single
purpose,
like
someone
adds
a
baggage
header
to
say,
like
force
a
request
or
something
like
that,
and
in
which
case
we
would
we'd
add
a
magical.
D
Attribute
we
have
in,
we
have
in
other
in
our
distributions.
We
have
a
java
distribution
at
honeycomb.
We
have
a
java
distribution,
we
have
a
net
distribution
and
in
both
of
them
we
have
a
baggage
span
processor,
which,
if
there's
a
field
in
baggage
baggage,
brand
processor,
extracts
all
the
fields
and
dupes
them
onto
the
current
spans.
B
D
It
is
well
it's
it's
related
in
that
context,
is
the
only
thing
that
carries
context
between
multiple
indications
of
like
what
what
information
do.
I
know
you
can
jam
stuff
on
context
and
then
get
it
in
a
child
spans
situation
to
use
a
different
word
other
than
context
and
because
baggage
is
by
default,
propagated
to
all
services
and
then
even
outside
of
your
system.
D
Unless
you
have
this
cross-reference
conversations
from
months
ago,
where
I'm
like,
is
there
any
way
to
turn
off
propagation
when
leaving
a
system
or
to
give
a
an
allow
list
of
who
who
receives
propagated,
headers,
maybe
you're
putting
the
user
id
on
all
child
spans
once
you
know
it,
if
you
put
that
in
baggage
it's
getting
propagated
out
to
like
any
third-party
api
you're,
making
an
http
call
to
right
so
right
so
we're
like
well,
maybe
maybe
we
shouldn't
use
baggage
like
that
until
such
time
as
the
spec
has
a
way
to
say
across
implementations,
here's
how
you
can
nerf
baggage
and
block
list
and
allow
list
it
all
right
well,
carry
on
it
just
stays
within
your
process,
and
then
you
can
choose
whether
you
dupe
that
into
baggage
like
it's.
D
It's
ways
to
opt
in
to
more
behavior,
so
in
trying
to
implement
just
the
in
process
thing
I'm
like
well
baggage
is
context
is
where
I
can
store
stuff
I'll
make
a
context
key
called
carry
on.
I
will
you
I
will
replicate
this
interface
of
setting
attributes
and
then
doing
a
with
attributes
so
that
I
have
a
scope
and
lean
in
on
all
of
that
automatic
attach
detach
scope
management-
that's
that's
baked
in
and
it
was
very
convenient
like
it's
very
convenient
to
just.
D
D
D
D
D
You
can
give
it
a
name
and
then
the
interface
for
jamming
things
into
context.
That's
sorted
out
for
you
and
in
a
world
of
like
yeah,
reduce,
reduce,
try,
reduce
wetness
in
a
dry
world
in
a
dry
world
like
baggage,
could
even
use
this.
I'm
just
jamming
things
into
context.
D
E
My
only
input,
I
guess
would
be
like
if
we
might
want
to
poke
around
to
see
if,
like
I
know,
javascript
has
tends
to
be
a
little
more
like
fast
and
loose
with
using
contacts.
So,
like
I
don't
know,
if
they're
using
a
helper,
maybe
it
benefits
us
to
stay.
You
know,
like
maybe
there's
some
benefit
there
like
look
at
what
some
other
cigs
are
doing.
E
I
don't
haven't
really
written
much
instrumentation
or
touch
stuff.
That's
using
context
too
much
so,
like
I
don't
know
I'd
kind
of
defer
to
people
who
are
touching
that
stuff
more.
D
The
the
the
siren
song-
and
I
admit
that
it
might
just
be
tempting
and
not
a
good
thing-
is
that
having
an
implementation
of
so
you
want
to
store
stuff
on
context.
Written
means
that
new
folks
coming
or
wanting
to
write
their
own
instrumentation
have
that
available
in
the
sdk
or
maybe
even
in
the
api.
D
Since
context
is
an
api
level
thing,
not
an
sdk
thing
right,
it's
so
you
want
to
store
stuff
in
context.
Here's
here's
a
way
to
do
it
and
you
don't
have
to
do,
but
maybe
that's
just
because
I'm
a
lazy
programmer.
B
I
was
gonna
say,
like
I
think
one
of
the
things
to
like
be
mindful
of
is
like
context
is,
I
hope,
I'm
not
misremembering
this,
but
it's
it's
intended
to
be
this.
Like
lower
level
thing
we
use
as
people
who
work
on
open,
telemetry,
ruby.
It's
not
necessarily
meant
to
be
surfaced
to
everyone.
B
As
like
a
consumable
api
again,
I
have
to
double
check
that,
but
it's
like
it
exists,
but
it's
not
like
the
selling
feature,
like
context,
is
very
much
this
thing
we
superimposed
on
the
ruby
language
to
support
our
needs
right
like
for
go
they're,
obviously
using
their
built-in
contacts,
so
we
we've
kind
of
replicated
that
so
like
it's,
not
that
I
I
think
we
should
disallow
people
from
using
it,
but
we
do
probably
want
to
kind
of.
I
think
this
is
kind
of
what
you're
saying
is
like
like
create
an
interface
for
interacting
with
it.
B
D
Certainly
because
I
wish
that
there
were
more
words
in
english
my
perspective,
my
the
context
for
this
desire
to
put
things
into
context
is
as
a
distributor
of
open,
telemetry
and
trying
to
add
features
to
either
open
telemetry,
ruby
itself
or
our
distribution
of
it
yeah.
So
it's
not
I
person
on
the
street.
It's
it's
it's
from
a
maintainer
of
another
yeah.
It's
either
from
an
hotel,
ruby,
maintainer
or
a
hotel
distribution
of
hotel,
ruby,
maintainer
perspective.
Oh
for.
B
Sure
I
didn't,
I
didn't
mean
that,
like
you
shouldn't
be
interacting
with
it
like,
I
think
the
carry-on
that
work
like
that's
something
that
I
think
would
be
interesting
if
it
existed
in
like
the
contrib
repo.
I
think
that
should
I
think
there
should
be
better
support
for
doing
stuff
like
that
as
well,
and
I
think
that
type
of
work
is
really
handy
and
I
think
it's
a
good
example
of
how
people
can
build
interesting
things
with
this
stuff
right.
D
B
E
All
I'm
saying
is
I'm
I'm
trying
to
avoid.
I
don't
know,
there's
a
open
question
I
have
is
like.
I
want
to
keep
the
people
using
open,
telemetry
ruby
as
their
offering
they're
delivering
to
like
end
users.
I
want
to
avoid
pushing
matt
and
rob
and
ourselves
or
whatever
I
don't
know.
If
the
goal
is
push
people
to
use
a
distribution
or
try
to
keep
it
all
in
the
core
thing,
and
it's.
E
E
E
It's
always
tough
to
like
answer
these
questions,
because
it's
unclear
to
me
a
little
bit
like
you
know,
but
I
don't
care
anymore.
D
So
I
I
hear
the
I
hear
the
concern
robert,
that
that
maybe
this
is
early
abstraction
of
like
drying
this
up
and-
and
you
know,
we've
all
had
this
conversation
about
it
and
maybe
we
dupe
it
like,
but
if
we,
if
you're
reaching
for
it,
we
maybe
it's
okay
to
dupe
it
until
it's
not,
then
we'll
know
it's.
B
I
wanted
to
just
like
I
just
think
of
like
previous
experiences,
where,
like
I've
worked
on
different
code
bases,
and
it's
like
it
starts
to
feel
muddled
like
I
don't
know
how
common
this
workflow
is,
but
like
often
when
I'm
working
on
something
and
it
doesn't
work
correctly,
I'll
open
the
gym
like
on
like
say,
I
have
like
a
rails
app
running
locally
and
I'll,
be
like
bundle
open,
xyz,
I'm
like
I'll,
take
a
look,
and
so
you
look-
and
you
see
this
class
that
you
think
the
method's
coming
from
and
you've
got
like.
E
B
B
B
E
D
Another
alternative
is
that
this
is
not
behavior,
that
you
mix
into
classes,
but
an
implementation
of
like
a
context
manager
and
then
something
that
uses
it
has
an
instance
of
putting
things
on
and
off
the
context,
so
that
it's
very
clear
this
is
an
instance
of
that
thing,
not
behavior.
That's
magically
mixed
in
it's.
There
are
ways
that
we
can
try
to
get
both
an
abstraction,
that's
well
tested
as
an
interface
to
jamming
things
on
context
and
try
to
make
the
code
readable
so
that
you
can
figure
out
where
behavior
is
coming
from.
B
All
this
is
to
say
is
like
I
wanted
to
make
sure
this
didn't
just
get
closed,
unceremoniously
without
any
discussion,
because
I'm
some
villainous
dictator.
I
wanted
to
make
sure
that,
like.
D
I
continue
to
do
luggage
experiments
and
maybe
I
can
experiment
with
something
that
you
get
an
instance
of
rather
than
behavior,
that
you
mix
into
something
and
see
how
that
feels
and
have
it
as
an
experiment
somewhere
for
people.
Looking
what.
B
Would
I
be
really
like
interested
in
seeing
exist
and
we've
talked
about
it
internally
on
some
of
the
stuff
we
do
because
we
chained
together
a
few
processors
francis
alluded
to
it
with,
like
I
don't
know
if
you
saw,
I
think
he
said,
like
talked
about
a
mutant
span,
processor,
somewhere,
yeah
that
that
that's
like
my
abomination,
I
would.
B
B
Yeah,
so
we
we
just
kind
of
informally
like
chain
these
processors
together.
In
my
mind,
I
don't
know
like
it
doesn't
seem
like
that's
defined
well
anywhere
like
formally
is
like
it
starts
to
feel
a
lot
like
middleware
right,
like
you
have
these.
E
B
Of
things
that
interact
with
your
spans
and
like
maybe
on
finish,
it's
immutable
and
you
do
something
hacky
and
you
introduce
interchange,
something
that
passes
along
something
immutable
because
whatever
you're
an
adult
and
you're
allowed
to
do
weird,
but
it
would
be
really
nice
for
us
to
whether
it's
in
contrib
or
somewhere
else
to
like
have
this
like
formal
structure
for
s-band
processor
pipeline,
so
people
aren't
left
to
just
like
finger
figuring
it
out
on
their
own
right,
like
they
can
just
like.
If
you
would
like
to
do
this,
this
is
how
you
do
it.
B
You
can
do
this
super
useful
thing,
and
it's
like,
I
think,
that's
what's
really
missing
in
in
my
mind,
just
like
this
is
deviating
from
the
original
conversation
a
little
bit
but,
like
specifically
thinking
of
like
your
carry-on
use
case
like
I
think,
that's
more
of
the
missing
piece
right
now,
because,
like
adding
baggage
or
any
other
context,
thing
is
like
the
snippets
are
tiny
right
like
that's,
not
necessarily
the
interesting
part.
It's
like
kind
of
what
you're
trying
to
do,
I
think,
is
a
lot
more
interesting
than
the
underlying
code.
D
A
kind
of
open
ended,
yeah,
the
that
you
can
add
things
to
context,
that's
carried
into
child
contexts.
D
English
is
useful
and
then
coupled
with
a
span
processor
pipeline
that
allows
you
to
do
more.
The
that
spans
coming
to
on
finish
immutable
is
highly
frustrating.
We've
had
to
point
to
hoping
that
people
could
are
willing
to
run
a
collector
and
then
collect
these
things,
because
a
collector's
allowed
to
mutate
things,
and
I
know
that
I
think
the
collector
contrib
repo
has
if
they
haven't
merged
it.
Yet
I
think
I
saw
a
pr
for
like
a
redacting
spam
processor,
where
you
can
go
and
strip
things
out
and.
D
It
exists
for
metrics,
but
it
didn't
exist
for
spans
until
recently.
Yeah
and
I
don't
know
the
state
of
it,
but
not
everybody
wants
to
run
a
collector's,
fair
yeah.
E
D
Well,
so
I
appreciate
bringing
this
up
robert,
because
this
was
something
that
I
was
interested
in.
I'm
cool
with
not
merging
it
now,
and
but
we
are
all
now
aware
of
it
as
a
thing
that
might
get
abstracted
in
the
future
cool.
B
And
to
touch
to
like
eric's
point
before,
where,
like
we,
we
obviously
have
the
presence
of
people
who
work
at
like
observability
companies
and
their
needs
might
not
be
exactly
the
same
as
our
own
as
like
just
end
users
of
it.
B
I
hope
it
goes
without
saying,
but
I'll
go
ahead
and
say
it
like
if
you
ever
feel
you're
not
getting
enough
like
if
we're
being
unfair
and
stubborn
and
not
allowing
through
useful
changes
like
please
like,
if
you
don't
want
to
do
it
on
a
recorded
zoom
call
like
you
can
find
me
on
slack,
and
I
will
listen
to
you,
because
it's
really
important
that
this
is
a
successful
project.
So,
like
part
of
that
means
having
like
receptive
maintainers.
D
I
think
this
conversation
was
the
opposite
of
not
receptive.
This
was
a
good
conversation
to
understand
why
your
hesitation
on
that
thing,
I
don't
know,
I
look
forward
to
experiments
that
will
have
us,
demonstrate
that
this
shouldn't
be
duplicated
or
confirmed
that
it
should
it's
cool
yeah.
B
Yeah
exactly,
I
think
that
the
tldr
is
like,
let's
just
wait
a
little
bit
longer
and
then
see
what
happens
and
like
if
it
ends
up
being
extracted
great
totally
changing
speeds
I've
merged
in
a
larger
pr.
The
other
day
this
one's
like
super
quick.
I
don't
even
know
if
it's
interesting
to
look
at
it's
just
introducing
a
gem
that
isn't
published
yet
since
it's
closed,
it'll
be
like
test
helpers,
be
the
title
I
think
yeah
there's
now
just
a
place
to
dump
test
helpers.
B
There's
like
there
was
with
end
was
being
defined
a
bunch
of
different
places.
We
had
introduced
a
test
helpers
file
in
common,
which
is
fine
for
like
the
time
being,
but
I
think
that
we
should
not
mix
our
runtime
and
test
dependencies
right,
even
though
the
test
helpers
in
common
wasn't
explicitly
being
required
anywhere,
you
have
to
like
go
and
yank
it
out.
B
I
just
think
that
it's
probably
a
little
bit
more
appropriate
if,
like
our
test
helpers,
were
only
ever
included
in
your
development,
environment
or
test
environment,
so
I
just
essentially
created
a
place
for
us
to
dump
that
stuff.
It's
a
lot
of
boilerplate
to
extract,
like
I
think
it
was
like
two
methods
which
is
kind
of
funny
leading
into
this
from
the
last
conversation.
But
I
think
this
is
useful,
because
now,
if
it
comes
up,
it's
like
we
just
know
where
to
put
this
stuff.
B
There's
a
test
logger
we
were,
there
was
like
repeated
calls
to
setting
the
the
the
open
telemetry
logger
to
this
log
stream
and
then
sending
it
back
like
that
was
repeated
in
quite
a
few
places.
There
are
some
places
where
we're
doing
mocks
and
stuff,
I'm
just
trying
to
introduce
a
little
bit
of
consistency
to
like
what's
an
easy
way
to
test
log
output
from
from
my
test.
So
it's
like
just
a
little
helper.
There
were
there
five.
B
I
getting
called
probably
yeah
there.
I
think
there
was.
B
But
it
was
more,
it
was
more
that
it
was
in
the
test
helpers
in
common.
As,
like
a
runtime
dependency,
I
didn't
think
that
really
made
sense
long
term.
So
yeah
again,
I
think
it's
kind
of
funny
leading
from
the
past
conversation
into
this
one,
but
hopefully
people
find
useful
more.
So
I'm
just
like
flagging
it.
So
people
know
it
exists.
Now
I
went
ahead
and
like
added
it
to
everything,
I
think
I
don't
think
I
missed
any
gems.
B
So
it's
like
you
can
just
count
on
like
these
open
telemetry
test
helpers
being
available
for
use
in
your
test
code.
I'm
going
to
add
some
instrumentation
helpers
like
there's
a
lot
of
like
reset
uninstall
instrumentation
calls
that
are
repeated
all
over
the
place
and
they're
like
doing
some
gnarly
things,
like
instance,
variable
set.
I
think
that
we
should
try
to
hide
that
away
a
little
bit
like
provide
like
a
useful
thing
for
doing
that.
B
So,
like
again,
we
if
we
decide
that
we
need
to
change
it
in
a
little
in
more
places
like
it's
just
easier
to
reach
into
and
then
and
then
eventually.
I
think
it
would
probably
make
sense
to
supply
some
test
helpers
for
people
who
are
consumers
of
inflammatory
ruby,
but
that's
not
the
immediate
target
audience.
It's
because,
like
we
have
internally
some
test
helpers,
where,
like
in
your
development
environment
by
default,
you'll,
get
like
a
simple
span
processor
with
the
the
in-memory
exporter,
and
we
just
set
it
to
recording
being
false
by
default.
B
But
then
we
just
provide
these
little
blocks
where
you
could
say
like
with
span
recording,
enabled
and
then
so.
If
you're
testing
some
operation,
you
can
see
all
the
spans
that
are
produced
as
a
result
of
that.
But
your
whole
test
suite
by
default,
is
not
going
to
be
just
bloating.
This
array
with
spans
so
some
stuff
like
that,
I
think,
will
find
its
way
into
there
as
well,
eventually,
if
it
makes
sense
but
yeah,
just
a
general
like
test
helper
for
for
our
stuff.
D
Is
that
in
memory,
what
was
it
called
blank.
B
B
We
have
like
a
kind
of
our
wrapper
gem
that
has
it
and
basically
what
it
does
is
it
like
sets
recording
to
be
true.
It
does
some
other
funky
stuff,
because
how
many
test
auto
runs
with
that
exit
hooks
and
then
it'll
like
clear
it
out
between
runs
fun
fact.
D
I
have
a
a
slightly
random
question
tuning
back
into
the
instrumentations.
I
see
that
there
is
a
an
active
support,
instrumentation,
which
seems
to
just
subscribe
to
active
support
notification
events
and
does
that
happily
take
all
of
the
fields
from
an
active
support
notification
event
and
put
it
on
a
span
and
ship.
It.
B
B
The
idea
of
that
jam
in
that
instrumentation
gym
was
that
it
provided
kind
of
like
a
general
interface,
because
there's
a
few
different
rails,
instrumentation
libraries
that
make
use
of
active
support,
and
so
basically
what
they
do
is
they
just
like
register
subscribers
for,
like
pre-defined
ones,
so
say
it's
like
you're
using
it
for
the
render
view
or
something
like
that.
B
The
render
view
instrumentation
all
it
does
is.
It
depends
on
the
active
support
notifications
and
then
it
just
like
registers
key
ones.
But
then,
if
you
are
like
a
rails
application
developer-
and
you
want
to
instrument
specific
notifications
that
aren't
being
instrumented
by
open
telemetry
for
whatever
reason
you
can
explicitly
register
specific
notification
topics,
but
I
forget
how
the
behavior
is
with
the
payload.
I'd
have
to.
D
I
could
experiment
I
was
while
I
had
people
here.
I
thought
I'd.
Ask
the
question,
because
honeycombs
beeline
is
a
very
naive
subscriber
to
events.
You
give
it
a
an
array
of
strings
which
are
event
names
and
it
will
transform
as
notification
events
into
honeycomb
events
and
ship
them
up
to
us.
So
there's
no
semantic
conventions,
it's
whatever
rails
called
it.
D
If,
if
there
was
a
way
of
like
if
you're
really
used
to
seeing
these
fields
on
your
traces
active
support,
instrumentation
in
hotel
ruby,
if
there
was
a
way
to
say
like
just
all
of
the
fields
on
that
event,
that
you
got
make
them
fields
on
the
span
and
ship,
it
like,
I
think,
that's
most
of
the
work
to
migrate
them
over.
B
There
is
sorry
that
is
the
right
thing
I
have
sent,
so
you
have
a
span
subscriber.
E
D
B
Oh
is.
D
B
Are
you
talking
about
like
notifications
or
the
payload
within
the
notifications,
because
there's
notification,
basically
like
topics
right
like
yes
rails,
has
like,
however
many
so
those
are
all
the
different
topics,
but
each
topic
might
supply
something
different
in
its
payload
right
right.
Well,
then,.
D
Okay,
I
think
I'm
just
trying
to
repeat
back
what
I
understand
so
the
active
support
instrumentation,
given
a
topic
we'll
just
give
you
a
span
back
with
the
event
payload
from
the
notification.
E
B
Yeah
yeah,
if
you
do,
if
you
just
spend
some
time
with
it,
think
about
that
config
option
that
one
just
at
a
glance,
I'm
sure
tim
thought
about
it,
but
I'm
not
sure
how
to
disallow
it
yeah.
It
seems
like
one
of
those
things
where
you
probably
want
like
opt-in
or
opt-out,
and
you
want
to
like
decide
which
one.
D
C
B
Yeah,
sorry,
if
there's
echo,
I
don't
know
yeah,
my
computer
decided
that
my
chrome
needed
to
restart
of.
D
Course
is:
does
this
active
support,
instrumentation
act,
sort
of
like
a
base
to
other
stuff
like
action
view,
would
use
this
to
subscribe
to
the
action
view,
events
and
then
have
a
specific
transformer
to
turn
it
into
semantic
convention.
Stuff?
Is
that
also?
This
is
something
that
I
can
just
go.
Look
at.
It
just
seems
like
a
possibility
of.
B
Yes,
so
yeah,
that's.
What
I
was
trying
to
say
before
is
that
this
is
kind
of
like
in
the
context
of
our
rails
and
instrumentation.
Active
support.
Instrumentation
is
a
building
block,
but
we
also
wanted
to
make
sure
something
that
I
was
pretty
adamant
about.
With
tim
when
he
was
setting
it
up
is
that
it
should
be
really
easy
to
use
standalone
as
well.
B
If
you
don't
want
the
rails
ecosystem
of
instrumentation
and
you
know
which
notification
topics
you
want
like
just
grab
that
and
do
your
thing
and
we've
kind
of
provided
a
path,
and
that's
one
thing
note
about
the
active
support
notifications
for
this,
because
I
know
in
the
past,
if
you
remember
like
we
were
all
kind
of
skeptical
or
I
was
skeptical
of
it.
I
think
real,
seven
and
up
fixed
that
skeptical
issue.
It
like
works
really
well
now,
just
by
default
and
the.
D
It
was
the
unreliable
exception
handling
when
a
chain
of
things
had
subscribed
to
stuff
excellent
cool
yeah,
someone
from
well
I'm.
D
B
B
So
we're
a
bit
over.
I
have
a
few
minutes
if
you
had
some
other
questions
or
anyone
had
any
other
questions.
Otherwise
I
could
let
everyone
run
away.
C
Well,
I
just
wanted
to
throw
something
out
really
quickly,
for
I
guess
the
three
of
you
who
are
here
sam
already
knows
about
this,
but
at
new
relic
we're
going
to
be
doing
a
twitter
space
focusing
on
open
telemetry
and
we're
trying
really
hard
to
find
people
who
want
to
come
on
and
talk
about
open
telemetry.
C
C
If
you
know
anybody
who
is
interested,
please
let
me
know,
because
we're
really
struggling
to
find
people
who
are
willing
to
come
and
just
chat
about
open
telemetry.
It
was
tentatively
scheduled
for
april
20th,
but
the
the
person
who's
leading
it
isn't
me
it's
another
one
of
my
co-workers,
but
they're
completely
willing
to
change
that.
If
there's
another
date
that
works
better
and
I
just
wanted
to
get
that
out.