►
From YouTube: 2021-03-30 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
B
A
A
D
A
Yeah,
I
think
matt
generally
does
all
the
work,
and
so
sometimes
it's
easy
to
forget
that
well
certainly.
B
B
E
F
That's
a
good
question,
I'm
not
sure
yeah.
I
think
he's
planning
to
join
so
yeah.
B
I
won't
if
anybody
doesn't
mind
I'd
like
to
take
notes
in
the
sig
document.
That's
cool.
E
That
is
totally
cool
I
feel
like
we
could
do
a
way
better
job
there.
I
figured
like
I'm
a
newborn
and.
E
Awesome
like
what's
the
better
and
yeah
do
I
have
this
thing
up
yeah,
so
this
fact
totally
take
notes.
The
other
thing
that
I
would
encourage
is
if
anybody
has
like
a
burning
question
or
some
topic
they
want
to
cover
like
feel
free
to
fill
this
in,
and
we
can
start
off
the
meeting
just
by
like
taking
taking
a
glance
at
least
like
noting
all
the
things
that
we
need
to
get
through,
so
that
things
don't
you
know,
drop
off,
so
we
can
best
best
manage
our
time.
I
guess.
A
I
had
one
which
is
general
to
open
telemetry,
but
I've
seen
some
work
here
that
I
think
a
colleague
of
francis
had
done
a
while
back
around
basically
open
tracing
shims.
A
I
know
it's
not
so
if
I
understand
correctly,
because
I'm
sort
of
starting
to
get
asked
around
it,
because
customers
ask
questions,
so
it's
not
required
for
a
1.0.
As
far
as
I
know,
an
open
tracing
ship,
but
it's
something
that
is
eventually.
Basically
all
the
languages
will
have
it
or
at
some
point
you
know
it'll.
It
should
get
added
and
is
the
goal
that
if
a
user
has
existing
open
tracing,
you
know
using
whatever
the
ruby
open
tracing
gem
instrumentation.
A
It
would
simply
that
whatever
some
custom
methods
that
are
instrumented
via
that
open
tracing
gem
would
essentially
just
like
run
through
the.
If
the
shims
enabled
correctly
it
would
run
through
the
open
telemetry
like
processing
and
export
pipeline,
like
under
the
hood,
it's
essentially
creating
an
open,
telemetry
spin.
F
Yeah
exactly
so,
the
parenting
relationships
should
still
work.
So
if
you're
mixing,
open,
telemetry,
instrumentation
and
open
tracing
instrumentation,
then
you
know,
child
span
should
be
created
correctly.
Context
should
be
propagated
correctly.
So
yeah,
that's
the
that's
the
goal.
I
think
there's
probably
a
couple
of
corner
cases.
I
haven't
gone
back
to
re-review
the
spec
yet,
but
there's
probably
a
couple
of
corner
cases
that
don't
quite
work.
The
way
you
might
like,
but
the
majority
of
things
should
just
should
just
work.
F
Cool
conventions
are
obviously
different,
but
yeah.
A
It'll
be
whatever
the
tags
are
or
attributes.
Okay,
that
makes
sense.
I
think
it's
a
useful
thing
to
have.
F
Yeah,
so
there
wasn't
much
of
us
the
open,
tracing
and
open
sensors
compatibility
pieces
weren't
ready
in
time
for
the
1.0,
I
believe
they're
both
there
now
we
will
probably
not
do
open
census
compatibility
just
because
the
ruby
implementation
of
open
sensors
never
left
alpha
we'll
do
open
tracing
the
pr
that
reese
had
started
a
while
back
is,
I
think,
significantly
different
from
the
approach.
That's
in
the
spec
now
so
no,
I
figured
it
was
easier
just
to
close
it
and
do
a
new
one.
A
Yeah,
I
think,
I'm
sure
it's
chain,
you
know
just
labels
versus
attributes
or
whatever
I'm
sure
stuff
has
changed
pretty
true
drastically.
Okay,
that's
good
to
make
sense
to
me
yeah.
There
might
be
something
in
the
future.
I'd
pick
up,
I
think
there's
some
vendor
benefit
like
there
might
be.
Some
may
be
able
to
get
time
allocated
my
job
for
it,
because
it
has
some
benefits
for
whatever
data
dog
cool
thanks.
I
don't
that
was
my
only
or
somewhat
smoldering
question
or
whatever.
F
I
have
a
couple
of
topics
I
want
to
touch
on
and
well.
Robert
wants
to
touch
on.
I
guess
and
now
he's
here
a
little
bit
later.
One
is
actually
the
biggest
one.
I
guess
is
just
we
we're
thinking
that
we
need.
Sorry
matt
brought
this
up
earlier.
The
fact
that
you
can
start
creating
spans
or
start
using
a
tracer
before
the
sdk
is
configured
and
thereafter
you'll
only
get
no
upstands
from
that
tracer.
F
So
we
want
to
do
a
refactoring.
Hopefully
we
can
get
done
this
week.
We
want
to
do
a
refactoring
so
that
you,
as
soon
as
the
sdk
is
installed,
even
if
you've
got
an
api,
tracer
you're
still
going
to
get
valid
spans
created,
like
sdk
spans
created
and
will
do
the
right
thing.
F
I
think
that's
relatively
easy.
That's
really
just
moving
span
creation,
responsibility
from
the
tracer
to
the
tracer
provider
instead
and
just
supplying
a
bit
of
extra
information
about
the
instrumentation
library.
So
the
only
state
that
the
tracer
instance
cares
about
is
instrumentation
library.
I
haven't
yet
looked
at
what
else
we
do
in
the
sdk
tracer.
Yet
there
may
be
some
more
stuff
that
has
to
move
the
slightly
related
topic.
Is
we
added
the
instrumentation
base
class
to
the
api?
F
I
think
we
should
actually
before
we
ga.
We
should
actually
extract
that
into
a
helpers
gem.
Instead,
I
don't
think
it.
I
don't
think
it
belongs
in
the
api
simply
because
it's
not
part
of
the
spec,
it
was
convenient
to
stick
it
there,
but
I
I
think
it
really
belongs
somewhere
else,
but
anyway
we
can
just
those
are
two
topics
I
want
to
discuss
a
little
later
in
the
meeting.
E
Okay,
did
I
capture.
E
Cool
yeah,
so
let's
go
through
the
spec
sig,
try
not
to
spend
time
and
then
move
on
to
these
issues.
That
sounds
good.
E
Oh,
I
think
we
covered
this
last
week,
but
there
is
this
user
research
survey
that
is
being
developed
and
a
lot
of
it
is
kind
of
based
off
of
this
document
here,
and
I
saw
that
became
added.
A
lot
of
comments.
E
But
I
think
the
tldr
is
that
there
is
a
there
is
like
a
draft
that
people
can
kind
of
like
run
through
and
then
give
feedback
on
the
fee.
I
think-
and
I
think
the
end
goal
is
to
kind
of
have
something
that
people
who
are
are
in
this
field,
or
you
know,
have
experience
with
tracing.
You
can
just
kind
of
throw
this
at
your
company,
maybe
grab
like
five
co-workers
and
have
them
try
to
provide
some
feedback.
E
Some
of
the
terminology
being
used
in
here
is
not
the
hotel
terminology
and
it
was
confusing,
like
I
think,
like,
for
example
like
calling
attributes
fields.
I
think
is
that
just
other
things
so.
E
Next
topic
up
was
baggage
tristan.
He
works
on
the
erlang
elixir,
implementations
was
working
on
their
baggage
system
and
I
think
the
biggest
question
he
was
having
is.
E
E
Yeah
one
reason
for
that
is
it's
like
the
easy
way
to
avoid
all
the
edge
cases
and
as
long
as
you're
key,
because
there
are
no
boundaries
really
for
what
can
be
a
baggage
key
in
hotel.
So
some
of
the
things
that
you
could
assign
to
your
baggage
like
in
process.
Technically,
you
couldn't
propagate.
But
if
you
do
url
encode
them,
you
can
like
the
worst
thing.
That's
going
to
happen
like
if
your
key
is
not
exotic.
E
The
url
encoding
of
it
should
be
the
same
as
the
original,
but
I
think
there
needs
to
be
some
clarification
around
that.
So
I'll
keep
an
eye
on
this.
I
kind
of
worked
on
our
baggage
and
if,
if
it
turns
out
that
we
just
want
to
like
match
against
the
regex
and
drop
like
I'll,
make
sure
that
we
get
that
update
in.
E
No,
it's
fine
yeah,
like
I
actually
kind
of
worked
on
some
of
this
record
exception
record
error
catastrophe,
so
I
made
sure
to
knock
my
mouth
at
all
during
this
conversation
because
it
it
went
on
forever
and
it's
like.
I
don't
know
it's
like
a
touchy
subject
that
I
think
like
has,
I
don't
know
it
doesn't
have
like
one
solution.
E
I
think
that
works
across
all
languages
and
paradigms,
I
think,
ends
up
being
the
problem,
so
it
there's
always
like
there's
always
an
issue,
and
I
think
here
I
think
the
the
main
issue
is
that
errors
and
exceptions
are
slightly
different
and
some
languages
both
some
have
one
or
the
other.
So
I
think
for
golang
they
have
errors,
not
really
exceptions,
so
it's
not
great
for
them,
but
the
api
method
is
called
record
exception
and
all
these
semantic
conventions
are
for
an
exception
and
they
were
trying
to
figure
out.
E
What
is
what
is
the
right
thing
to
do
here
and
I
think,
there's
differing
opinions
but,
like
I
think
in
general,
because
the
semantic
conventions
are
exception
based
and
they
didn't
really
want
to
have
a
special
case
for
go
just
because
back
ends
want
to
do
something
special
with
this
information,
I
think
the
go
sig
was
amenable
to
sticking
with
the
exception
terminology,
especially
for
the
for
the
telemetry
output,
because
they
were
going
to
stick
with
it
for
the
telemetry
output.
E
I
think
they
were
going
to
stick
with
it
for
the
for
the
api,
but
I
think
they
were
going
to
possibly.
E
E
Jana
was
asking
about
how
to
add
a
new
telemetry
type,
which
is
yet
another
landmine,
but
then
looking
at
recording
data
that
isn't
really
tracing
data,
it
isn't
really
metrics,
so
they
were
talking
about
kind
of
like
an
event
type.
F
A
little
where
this
is
this
is
for
sampling
profilers,
and
this
is
actually
really
important.
We
have
been
we
shop
if
I
have
been
politely
asking
for
this
since
open
telemetry
started,
so
we
probably
won't
get
to
working
on
this.
I
would
say
this
year,
but
it's
certainly
something
that
we're
keen
to
support
in
the
open,
telemetry
collector
and
we're
keen
to
support
an
open,
telemetry
ruby.
This
is
actually
incredibly
important
for
us
and
having
the
ability
to
correlate
profile.
F
Data
with
trace
data
is
incredibly
powerful,
so
yeah.
What
was
the
sentiment
at
the
spec
sig
around
this.
E
I
think
I
think
the
sentiment
was
they
would
look
for
something
like
this.
Like
I
didn't
get
the
impress,
I
didn't
get
a
strong
feeling
as
to
whether
this
would
be
like
a
totally
separate
stream
of
events,
but
I
know
like
this
is
coming
from.
E
I
think
this
is
coming
from
jana
and
and
amazon
and
generally
like
the
thing
that
they
were
hoping
to
do
is
come
out
with
some
output
essentially
brought
or
compatible
with
it,
because
there's
so
much
tooling.
F
On
it,
yeah
prof
supports
everything
you
need.
It
supports
labeling,
and
it's
easy
to
well
relatively
easy
to
combine
profiles
as
well
with
profs,
so
yeah.
I
I
think
trying
to
adopt
existing
standards
and
meet
our
requirements
would
be
a
better
approach
than
trying
to
invent
something.
New
here
seems
to
be
getting
us
into
trouble.
Yeah.
E
F
It's
it's
not
terrible.
It
like
I've
implemented
this
previously
and
after
I
stopped
implementing
it
for
alcohol
model.
Five
new
implementations
cropped
up
for
it
in
our
core
monolith,
so
in
the
one
code
base
yeah,
you
work
with
smart
people.
Well,
we
work
with
people
talk
to
one
another,
maybe.
A
E
So
there
have
been
these
missing
improvement
projects
that
have
been
ongoing.
There's
four
of
them.
I
think
there's
two
of
them
that
are
kind
of
two
of
them
have
been
happening
in
in
tandem,
but
I
think
one
of
them
is
getting
paused
a
little
bit,
and
that
is
the
the
convenience
api
project.
Really.
This
is
just
being
operated
as
a
an
asynchronous
fact
fashion,
over
kind
of
slack
and
google
docs,
but
ted
was
kind
of
saying
you
better
get
some
user
feedback
on
what
they
like
and
don't
like
about.
E
F
We
had
been
looking
to
pump
the
with
span
thing
until
this
convenience
api
was
somewhat
settled.
Should
we
reconsider
that
yeah.
E
Kind
of
wispan
in
span,
both
of
them
are
kind
of
like
things
this
I
don't
know
I
feel
like
this
is
something
we
need
to
talk
about,
to
figure
out
what
we're
going
to
do
here
and
yeah.
I
do
think.
E
We
should
talk
about
this
and
I
think,
really,
I
wouldn't
mind
doing
a
survey
of
some
of
the
other
languages
to
see
what
what
is
there
and
what
people
have
done.
I
think
that
that
is
maybe
our
first
step
and
then
based
on
based
on
that,
we
can
start
to
make
some
decisions
as
whether
we
keep
it
remove
it,
and
if
we
keep
it
what
the
behavior
should
be.
E
All
right
yeah,
that
sounds
like
sounds
like
a
good
idea.
I
guess
I
can
take
that
action
item
to
at
least
get
this
discussion
going
and
start
some
of
that
research.
E
E
So
there
is
an
instrumentation
project,
that's
kind
of
one
of
the
other
four,
but
this
is
like,
I
think,
the
one
that
is
is
most
important
and
that
everyone's
gonna
focus
on
right
now,
the
other,
the
other
three,
I
guess
are
on
the
back
burner
for
now,
but
discussions
are
happening
in
the
instrumentation
slack
channel
and
I
think
the
the
idea
is
to
kind
of
get
some
kind
of
like
uniformity
or
standards.
E
I
guess
four
different
types
of
instrumentation
between
kind
of
languages,
so
that
I
think
a
lot
of
it
just
kind
of
comes
around
to
eventually
all
this
telemetry
data
ends
up
in
some
sort
of
tracing
backend,
and
you
know
you
very
likely
have
some
heterogeneous
setups.
C
F
I
noticed
I,
I
think,
there's
generally
a
sense
that
you
know
semantic
conventions
are
great,
but
they
don't
go
far
enough
in
terms
of
describing
sometimes
relationships
between
spans
or
all
the
different
circumstances,
where
you
should
create
a
span
of
one
kind
or
another,
so
that
that's
one
thing,
the
other
portion,
which
was
really
interesting.
I
just
skimmed
this
document
right
now,
there's
a
discussion
of
how
we
should
distribute
the
auto
instrumentation,
distribute
and
configure
it
we've
we
kind
of
have
a
foot
in
two
camps
here.
F
There's
the
two
big
approaches
are
either
separately
distributing
packages
or
having
an
all-in-one
package.
We
actually
have
separate
gems
for
each
piece
of
auto
instrumentation
and
then
an
all-in-one
instrumentation
gem
as
well.
That
just
enables
or
depends
on
all
our
existing
auto
instrumentation.
E
Yeah,
I
do
think
there
are
slightly
different
considerations
with
auto
instrumentation
between
at
least
things
like
java,
where
we
do
this
code
manipulation.
I
think
it's
hard
to
distribute
only
things.
At
least
that's
the.
E
That's
the
sense
that
I've
gotten
from
just
listening
to
those
discussions.
I
don't
understand
all
the
details,
but
I
feel
like
for
like
dynamic
languages,
it's
really
easy
to
kind
of
do
what
we've
done,
and
there
does
seem
to
be
like
a
slight
difference
in
strategy
between
those
those
ecosystems
but
yeah.
I
guess
we
will
keep
an
eye
on
on
those
conferences
and
make
sure.
E
At
some
point,
I
guess
we
can
have
the
discussion
about
like
how
how
useful
it
is
to
distribute
things
as
as
we
are,
but
I
think
we
went
for
the
that
gave
like
a
wide
degree
of
like
flexibility
like
you.
Can
you
know
curate
your
own
list
of
packages
if,
if
you
would
like-
or
you
can
just
use
this
all
in
one,
if
you
would
just
like
at
all,
seemed
like
a
good
idea
at
the
time
we
can
see
how
that's
working
out
for
everyone.
B
Is
that
is
that
a
known
disadvantage
right
now,
because
I'm
actually
a
fan
of
you?
Can
you
can
get
the
all
package
and
then
you
get
all
of
them
and
you
didn't
have
to
think
about
it
and
then
at
a
point
where
that
becomes
burdensome,
you
can
turn
off
all
and
then
cherry-pick
the
instrumentations
that
you
want
is
that
have
we
seen
that
that's
been
problematic.
F
The
two
problems
that
come
to
mind
one
is
just
remembering
to
add
new
instrumentation
to
that
all
instrumentation,
but
that's
not
terrible.
It's
a
challenge
to
the
maintainers
to
like.
F
Yeah,
so
that's
one
challenge
for
some
people
who
are
particularly
concerned
about
boot
performance,
boot
time
performance
of
their
application,
they're
a
little
fanatical
about
the
number
of
gems
that
they
pull
in.
So
that
could
be
a
concern
for
some
people.
Imagine
I
imagine
that
could
get
documented,
though,
like
don't
use
the
all.
If
you
care
about
bhutan,
yeah,
yeah
yeah,
totally
totally
yeah
yeah,
it's
just
you
know.
We
should
make
the
documentation
clear
that
this
is
the
trade-off
that
we're
making
the.
F
I
can't
remember
offhand
whether
the
all
instrumentation
is
noisy
when
you're
not
able
to
enable
certain
things
robert
is
nodding,
so
I
I
think
we
probably
spit
out
a
whole
bunch
of
errors
for
all
the
instrumentation
that
wasn't
able
to
be
enabled,
because
you
didn't
have
the
dependencies
installed.
G
So
for
like
even
we
have
an
internal
raptor
gem
that
pre-configures
telemetry
ruby
and
we
hand
select,
which
instrumentations
to
include
similar
to
all,
but
it's
just
not
all
it's
the
ones.
We
know
that
are
commonly
used
at
shopify
and
I'm
in
the
process
of
migrating
so
for
context.
I've
migrated
like
three
to
four.
G
So
far,
now
the
first
two
immediately
in
their
development
environments
set
the
open,
telemetry
logger
environment
to
be
whatever
so
that
it
would
just
disable
it,
because
people
were
complaining
about
every
time
they
bring
up
a
console
or
started
their
local
dev
machine.
They
get
like
a
wall
of
messages
like
this
saying,
failed,
failed
installed
and
sold
installed.
So
that
is
something
that
seems
minor,
but
people
really
really
care
about.
Apparently,.
F
Yeah
there
was
another
circumstance
where
somebody
was
asking
for
verbose
logging.
F
There
are
people
who
want
it
to
be
really
noisy
because
they
want
to
see
all
errors
early
and
then
there
are
other
people
who
just
see
it
as
noise.
We
need
to
figure
out
which
camp
we
want
to
satisfy.
I
think
it
would
be
helpful
to
have
maybe
a
couple
of
additional
helpers
that
allow
you
to
just
set.
You
know
verbose
logging
with
full
stack
traces
for
the
people
who
really
want
that,
but
maybe
a
more
same
default,
at
least
for
instrumentation.
That
is
a
little
less
noisy.
E
Yeah,
so
I
think
what
I'm
hearing
here
is
in
general,
the
system
could
use
some
improvements,
but
the
general
idea
of
being
able
to
have
an
awl
or
a
curated
package
is
there.
There
are
probably
some
merits
there,
but
we
we
can
improve
documentation
and
we
can
improve
kind
of
the
chattiness
of
clogs
when
things
don't
work
out,
and
I
think
we
should
definitely
track
all
these
things
and
make
these
improvements
and
all
in
all,
I
think
that
would
be
good
feedback
for
for
this.
E
You
know
for
this
working,
I
guess
ultimately,
as
as
we
have
these
package
distribution.
E
All
right,
I
guess
we
have
things
gonna
wrap
up
like
the
one
thing
that
I
did
kind
of
see.
Some.
I
think
it's
this
link,
but
I'm
gonna
click
from
here,
because
I
definitely
noticed
this
link
is
that
there
there's
some
structure
at
least
around
one
of
these
sub
items
on
that
list
and
that's
the
http
instrumentation.
E
I
think
francis
was
kind
of
alluding
to
this
when
he
was
summarizing
the
other
doc,
but
it's
kind
of
at
least
kind
of
has
like
the
bullet
points
of
like
the
open,
open
questions
that
are
that
they're
trying
to
resolve
and
the
sort
of
kind
of
standardization
that
they're
trying
to
provide
between
different
http
libraries
so,
like
should
clients
have
more
than
one
span
and
like
I,
I
think
these
are
problems
that
we
kind
of
struggled
with
it's
like
what
happens
when
we
try
to.
E
We
start
getting
these
potentially
like
nested,
client
spans
and
we've
found
solutions
around
those
in
the
same
thing,
with
fans
and
generally
like
things
should
be
spans
and
events.
It
does
look
like
it's
mostly
empty
bullet
points.
E
I
guess
that's
it.
The
document
starts.
F
E
Concerns
all
right.
E
Yep
yeah
francis
mentioned
a
couple
of
items
we're
interested
in
upfront
yeah.
G
I
just
want
to
quickly
like
throw
a
little
update
on
the
active
record.
Instrumentation
andrew
was
kind
enough
to
test
it,
unsuccessfully
he's
having
some
troubles
with
it.
So
the
way
I
tested
I
tested
on
basically
a
rails
new
app,
but
then
I
also
put
it
up
against
our
core
monolith
and
my
mind
was
like:
oh,
that's
like
a
pretty
wide
scope
of
our
pre,
just
very
different
applications,
one
that's
like
16
years
old
and
one
that's
like
16
minutes
old
and
they
both
work.
So
I
thought
it
would
be
good.
G
G
So,
if
anything,
references
a
model
before
the
sdk
gets
initialized
with
the
active
record
instrumentation,
it
does
not
work
just
flat
out
it
patches
the
persistence
class
and
any
any
of
the
class
that
I
patch
they
get
patched
after
they
get
included
on
the
models,
and
so
the
models
don't
have
the
patches,
and
I
spent
a
couple
days
last
week
or
something
like
that
trying
to
work
around
it
unsuccessfully,
and
I
got
a
little
bit
discouraged.
G
So
I'm
now
working
on
other
stuff,
but
if
anybody
has
any
ideas
of
how
we
might
be
able
to
get
around
this,
please
leave
a
comment
or
let
me
know
I'm
not
like
given
out
there
done
with
it
by
any
means.
It's
just
I'm
just
shifting
my
attention
for
the
moment,
hoping
I'll
come
back
with
some
sort
of
newfound
brilliance.
C
E
Yeah,
I
always
hope
that
I
can
find
some
hook
in
in
the
rails
boot
cycle
that
will
ensure
that
this
runs
at
the
right
time.
But
if
the
problem
is
that
our
stuff
gets
required
too
late,
then
that
becomes
a
a
harder
mission.
I
guess.
B
G
Yeah
so
like
yeah,
if
anybody
has
any
ideas-
or
maybe
their
past
experience
with
rails,
has
shown
them
like.
Actually
you
can
somehow
get
in
here
and
it'll
work.
That's
what
I'm
looking
for,
because
I
am
really
disappointed
because
I'm
concerned,
I
won't
be
able
to
stick
with
this
general
approach.
I
really
do
like
the
types
of
spans
and
traces
that
get
generated
from
this
instrumentation.
I
think
there's
a
lot
of
potential
to
just
surface
a
ton
of
value
on
a
rails
application
with
this
approach.
G
A
A
Oh
I'm
blanking
now,
but
maybe
using
a
rail
tie.
We
might
be
able
to
get
it
to
work,
but
not
in
all
situations
like
that,
wouldn't
it
that
might
be.
That.
Might
that's
not
a
great
solution
overall,
but
it
might
be
caveat
around
like.
If
you
want
to
use
active
record,
you
have
to
use
a
rail
tie
or
we
could
suggest
a
real
tire
as
some
sort
of
auto
instrumentation
realtor
or
something
I
don't
know.
G
Yeah,
I
am
using
a
rail
tire
for
our
internal
wrapper,
so
that's
I
I've
actually
like
put
the
previous
rails
instrumentation.
I
granted
an
issue
where
it
wouldn't
work
for
everyone
that
wasn't
using
real
time.
I
managed
to
get
around
that
I
haven't
played
because
I
think
there
is
potentially
different
types
of
real
ties.
I
haven't
revisited
that
yet
and
yeah
so
like
our
wrapper
is
a
real
type.
So
someone
just
requires
the
gem
and
then
their
application
is
instrumented.
G
They
don't
actually
have
to
do
anything
other
than
add
the
gem
to
their
project
and
everything's
just
good
to
go.
So
that's
all
done
through
rail
ties,
so
I
have
to
look
at
seeing
if
there
is
like
an
earlier
hook
that
I
can
grab
onto
like,
I
said
I'm
just
kind
of
taking
a
micro
hiatus
from
it.
While
I
push
more
applications
to
open
telemetry
at
shopify,
that's
what
I'm
kind
of
focusing
on
last
week
yeah.
So
I
will
give
that
another
shot.
That
is
a
good
reminder
to
spend
some
time
in
advance.
A
Yeah,
it's
probably
I'm
thinking
through
it
more.
I
probably
won't.
You
can
add
it
before.
You
add
all
those
like
initializer,
you
can
have
it
run
before
all
the
initializer
files,
but
active
record
wouldn't
be
in
configuring,
an
initializer,
okay,
I'll,
look
at
the
issue
or
the
the
pr
I'll
suggest
something
if
I
have
advice,
but
I
think
we're
screwed.
G
Francis
did
mention
had
some
points,
but
I
don't
know
if
there
were
some
others
before
that,
because
I
should
have
played.
I
don't
want
to
jump
the
lines
if
there's
anything
or.
F
No,
those
those
are
the
ones
we
don't
want
to
dive
into
so
instrumentation,
based
class,
moving
that
out
of
the
api
gem
into
some
other
helper
gems.
That
was
one
and
the
somewhat
related
issue
of
moving
functionality
from
tracer
to
tracer
provider,
so
that
you
can
create
a
tracer
before
the
sdk.
They
ask
for
a
tracer
before
the
sdk
has
been
initialized
and
then
once
the
sdk
has
been
initialized,
you
correctly
create
sdk
spans
instead
of
api
spans.
G
So,
as
I
mentioned
before,
I'm
in
the
process
of
doing
first-party
instrumentation
for
the
google
apis
core
jam
just
basically
tracing
the
kind
of
http
requests
that
come
out
of
there
at
around
the
same
time.
We
had
someone
approached
us
internally
for
a
gem
we
have
built
inside
and
they
wanted
to
add
tracing
as
part
of
it.
So
it's
a
it's
a
client
gem.
G
It
uses
grpc,
unfortunately,
but
while
I
was
setting
it
up,
they
have
their
own
kind
of
initialization
life
cycle,
and
I
was
looking
at
using
instrumentation
based
class.
I
thought
yeah.
I
know
this
would
be
great,
but
I
think
ultimately,
one
of
the
issues
we're
going
to
face
is
how
do
we
handle
if
they
they
initialize
the
tracer
wallets
at
noaa
tracer
right?
So
one
of
the
kind
of
ideas
I
had
was
well.
G
So
I
talked
about
that
a
bit
with
francis
and
kind
of
came
to
the
conclusion
that,
like
I,
was
hoping
that
it'd
be
just
as
easy
as
someone,
including
the
api,
this
instrumentation
based
class,
and
then
they
can
unconditionally
trace
whatever
it
is
they're
concerned
with.
But
like
the
points
I
just
kind
of
went
in
with
it
doesn't
seem
like
a
good
idea.
So
I
think
there's
no
really
getting
around
that.
G
You
probably
don't
want
to
trace
the
noise
tracer
ever
it
just
seems
like
potentially
dangerous,
but
also
you
don't
want
to
have
to
have
a
bunch
of
code
in
like
I
guess
you
don't
really
want
the
the
jam
you're
instrumenting
to
have
to
constantly
check
either
and
like
try
to
keep
fetching
anyone.
G
So
you
don't
have
to
like
go
through
trying
to
see
as
the
sdk
there's
the
sdk
there
over
and
over.
I
don't
know
if
that
makes
sense,
but
that's
that's.
The
motivation
behind
having
the
api
be
self-sufficient
enough
that
when
the
sdk
is
set
up,
it
knows
to
use
that
in
its
place
and
it's
it's
more
of
the
responsibility
of
the
api
and
not
the
first
party
instrumentator,
the
other
part
of
that
and
I'll
like
actually
I'll
pause
there
and
see.
If
anybody
has
any
comments
or
thoughts.
E
Yeah,
I
was
just
gonna
say,
like
I
think,
somewhere
the
spec
actually
kind
of
says
something
along
these
lines.
There
was
this
global
init
spec
at
one
point
it
might
be
a
otep,
but
it
basically
said
that
if
a
user
gets
a
no
operator
from
the
api
with
an
sdk
is
later
installed
like
the
tracer
should
become
operational
and
the
way
the
way
I've
seen
this
done
in
other
languages
is
that
the
the
api
tracer
provider
returns
a
tracer
proxy
that
actually
delegates
to
the
backing
trace.
E
Maybe
a
no
op
tracer
or
it
may
get
kind
of
point
to
like
an
operational
tracer.
But
I
think
there
are
probably
other
ways
to
do
this
as
long
as
that
one
rule
kind
of
holds
that
if
you
get
a
no
op
trace
early
because
an
sdk
is
not.
Unless
that
it
turns
into
a
operational
tracer,
then
you
should
be
in
good
shape.
G
Yeah,
so
the
the
second
related
part,
that
makes
sense,
I
agree,
like
makes
sense.
The
second
part
relates
to
extracting
the
base
instrumentation
class
from
the
api,
because
it's
something
like
our
own
creation,
it
really
shouldn't
be
in
the
api,
and
so
I
was
obviously
a
proponent
from
it
for
it.
The
last
time
you
talked
about
it
saying
hey
for
spreading
instruments
should
yeah.
Let's
have
them
use
this
base
instrumentation
class.
G
I
still
think
parts
of
it
are
a
good
idea,
but
I
realized
that,
like
we
do
want
to
push
first-party
instrumentation
to
adhere
to
the
api
strictly
so
that
they're
compatible
with
sdks
that
are
not
our
own
and
if
we
do
push
them
to
do
to
use
the
base
class,
then
they're
losing
potentially
that
compatibility
layer
with
other
sdks
not
that
they
exist
right
now,
but
I
think
we
should
preserve
the
intention
of
separating
the
api
from
the
implementation.
G
So
I'm
going
to
go
back
on
that
and
say
that
first-party
instrumentation
instrumentators
should
not
use
this,
even
if
it
does
have
some
niceties
baked
into
it.
So
that's
that's
part
of
the
motivation.
There
is
like,
let's
actually
get
that
done
before
our
1.0
release.
Let's
extract
it
out
and
my
intention
there
I'm
not
super
overly
picky
on
what
packages
things
should
go
into.
G
I
was
thinking
of
just
having
an
open,
telemetry
instrumentation
base
gym
that
contains
kind
of
that
small
supporting
work,
and
that
would
be
something
that
our
third
party
instrumentation
classes
would
require.
In
addition
to
that,
this
is
not
as
related.
I
want
to
do
an
instrumentation
based
like
test
helper
gem
for
people
who,
for
like
some
of
the
test
things
we
do
are
kind
of
okay,
like
we
will
dive
into
the
instrumentation
instance
and
reset
the
install
variable
default
so
just
like
instance,
variable
set
and
it's
kind
of
like
hanky.
G
So,
like
you
know,
you
never
put
that
in
your
your
code,
hopefully
for
like
a
production
app.
So,
let's
like
set
up
some
test
helpers,
even
if
the
test
helpers
are
doing
that
under
the
hood.
That's
okay,
but
let's
provide
like
a
reasonable
way
to
reset
instrumentation
between
tests
that
as
that
changes
with
instrumentation
based,
we
just
provide
like
a
clean
way
of
like
resetting
that,
because,
even
in
the
case
like
between
tests
right
now,
we're
just
setting
that
install
flag
to
false
the
the
tracer.
G
That's
provided
by
the
instrumentation
instance
will
still
be
potentially
an
sdk
for
sdk
tracer
instead
of
the
no
op
tracer
that
goes
by
default.
So
like
we,
don't
have
a
clean
way
of
doing
that.
So
I'm
just
proposing
that
we
have
like
a
test
helper
for
this
instrumentation
base
to
make
life
easier
for
us.
F
Just
looking
at
the
spec
at
the
moment,
there's
a
potential
ambiguity
between
having
a
like
being
able
to
upgrade
traces
as
it
were,
and
what
the
spec
actually
says.
So,
the
the
specs
is
it
an
sdk.
Tracer
is
required
to
create
an
instrumentation
library
instance
that
is
stored
with
the
tracer,
it
doesn't
say,
and
the
instrumentation
library
is
an
sdk
concept.
It's
not
an
api
concept,
so
that
introduces
a
little
bit
of
complexity
like
if
you're
strictly
adhering
to
it.
F
You
know
the
you
can't
take
your
tracer
instance,
your
api
trace,
for
instance,
and
make
it
like
turn
it
into
an
sdk
tracer
instance
directly
like
that.
So
that's
that's
one
thing.
The
other
thing
is
that
the
api
spec
is
very
specific
about
being
able
to
support,
creating
an
arbitrary
number
of
tracer
providers.
F
In
order
to
create
traces
that
have
different
configurations
or
use
different
span
processes,
I'm
just
not
totally
sure
how
this
is
all
going
to
gel
and
still
be
spec
compliant.
I
just
think
the
spec's
a
little
ambiguous
about
support
for
both
of
those
things.
B
I've
seen
and
I've
only
experi
in
java.
I
won't
I've
only
experimented
with
it
for
about
48
hours,
but
in
the
hotel
implementation
for
java,
there's
like
a
registering
a
global
tracer,
but
you
can
instantiate
other
tracers
to
use
in
different
contexts
if
you
needed
to,
but
again
that
doesn't
clear
up
ambiguity
in
the
spec.
It's
just
how.
F
Yeah,
the
problem
is
interpreted
right.
The
problem
here
is
that
if
we
had
two
different
traces
created
with
two
different
instances
of
the
api's
tracer
provider,
then
if
we
have
this
upgrade
thing,
then
as
soon
as
you
install
the
sdk,
those
two
traces
are
actually
going
to
act
as
if
there
are
sdk
traces
and
that
may
not
be
the
intent.
I'm
not
entirely
sure
that
may
not
be
the
intent
of
the
user.
F
E
I
think,
for
that
particular
use
case.
It
depends
on
where
you
got
what
tracer
provider
you
got
the
tracer
from
so
like
the
one
thing.
I
think
that
the
spec
is
pretty
clear
on
is
that
there
can
only
be
one
global
tracer
provider
and
that
you
can
have
other
tracer
providers,
but
you're
kind
of
on
your
own
for
like
managing
the
creation
and
access
to
it.
E
F
Yeah,
that's
that's
fair.
I
mean
there's
two
complexities.
There.
One
is,
if
you're,
using
two
different
sdk
implementations
in
the
same
application,
which
would
be
really
interesting,
the
other
which
I
don't
think
is
a
supported
mode
for
open
telemetry.
F
The
other
is,
if
you're,
actually
asking
for
two
different
tracer
provider,
instances
or
you're
using
the
global
one
and
then
a
specially
configured
one,
the
it's
a
little
bit
interesting,
because
the
api
spec
talks
about
that
in
the
context
of
configuration
and
spam
processes,
which
are
only
concepts
from
the
sdk
than
our
concepts
from
the
api.
F
F
F
F
E
You
said
a
lot
there,
but
I
will
just
kind
of
back
that
all
up
with,
like
you,
always
think
the
spec
that,
because
every
other
sig
has
done
something
the
spec
is,
you
know
the
spec
establishes
what
needs
to
be
done,
but
I
always
usually
find
when
you
start
to
like
get
into
the
details.
You
find
that
there
is
some
stuff
missing
and
it
ends
up
being
this
kind
of
like
research
mission
to
figure
out
what
have
other
cigs
done
like
do.
E
So
if
you're
finding
there
are
some
holes
and
that
there
needs
to
be
some
clarification
like
I'm,
not
shocked
and
we
yeah
as
we
move
through
this,
we
can
kind
of
get
through
this
and
hopefully
improve
the
spec
in
like
in
a
way
that
is,
I
don't
know
things
get
more
complicated
now,
that
kind
of
add
a
1.0.
I
guess,
but
I
made
some
clarifications
around
bc
that
worked
out,
and
just
you
know
it.
E
It
happened
that
the
words
you
know
were
really
just
kind
of
clearing
and
did
not
really
break
anything.
So
we
might
find
that
to
be
the
case
as
we
work
through
this
and
kind
of.
E
I
guess
the
other
thing
that
I
was
just
to
follow
up
to
robert's
comments
about
the
extracting
instrumentation
base
and
having
helpers
and
in
general,
like
I
think,
I'm
thumbs
up
on
all
of
that
like
and
I
think
you've
done
a
lot
of
the
work
to
kind
of
figure
out
how
how
things
might
work
for
like
a
third
party
gem.
So
I
feel,
like
you,
have
the
most
expertise
and
how
to
get
all
this
working
well
together.
E
G
G
Is
there?
Is
this
a?
I
guess?
Maybe
just
is
this
a
bad
idea?
You
know
famous
words
to
start
a
sentence
having
first
party
instrumentation
establish
that
it's
only
compatible
with
a
specific
sdk
is
like
that's
something
we
want
to
avoid
like
the
play
or
is.
F
E
E
If
we
pull
that
out,
then
in
general
we
would
expect
that
they
would
not
use
it.
I
guess
would
be
the.
F
Yeah
first
party
instrumentation
shouldn't
have
to
use
the
and
we
shouldn't
even
necessarily
recommend
that
they
use
the
instrumentation
based
class.
We
can
suggest
it
as
an
approach
if
they
want
it,
but
I
don't
think
we
should
necessarily
recommend
it.
The
auto
instrumentation
they
can.
It
shouldn't
depend
on
the
sdk
at
runtime,
but
it
can
depend
on
this.
You
know
instrumentation
base
gem.
F
E
B
F
F
Instrumentation
so
first
party
instrumentation,
is
if
I'm
writing
the
radius
gem
as
an
example,
and
I
want
to
take
a
dependency
on
open,
telemetry
and
add
my
spans
directly
there,
instead
of
having,
instead
of
like
needing
this
auto
instrumentation
that
goes
in
and
patches
the
redis
gem.
F
So
as
the
author
of
the
redis
jam,
if
I'm
using
open
telemetry
in
my
gem,
that
is
first
party
instrumentation,
if
I'm
an
author
of
open
telemetry
and
I'm
writing
a
gem
that
patches
the
redis
gem,
then
that's
third-party
instrumentation.
So
the
insta.
B
F
F
Finally,
it's
great
to
have
that
in
thomas's
last
words,
so
he's
done
with
it
now
he
never
needs
to
think
about
token
ever
again,
which
is
amazing,
so
the
one
outstanding
thing
we
have
for
the
aussie
right
now
is
my
apr.
I've
applied
feedback
or
I've
responded
to
feedback.
I've
made
the
b3
propagator
updates.
There's
a
couple
of
merge
conflicts
around.
I
think,
probably
related
to
the
baggage
updates
that
I
need
to
work
into
this
pr,
but
otherwise
this
is
substantially
complete
and
it'd
be
really
great.
F
If
we
could
get
some
more
eyes
on
this,
because
it's
a
pretty
big
refactor.
G
E
F
Yeah
now
that
would
be
really
really
helpful,
and
if
we
can
get
this
wrapped
up
this
week,
then
maybe
we
can
have
an
rc
as
a
easter
egg
or
something
I
don't
know.
E
All
right,
great
anybody
have
anything
else.