►
From YouTube: 2021-07-06 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
Seems
like
it's
about
the
usual
time,
so
I'll
go
ahead
and
get
started
more
people
may
trickle
in.
A
A
A
A
Apparently,
this
is
kind
of
coming
from
the
java
world,
specifically
something
that
happened,
perhaps
with
apache
camel
but
they're,
starting
to
run
into
this
ecosystem.
I
are
trying
to
run
into
problems
over
in
java,
where
people
are
or
frameworks
are
starting
to
add,
open,
telemetry,
natively
and.
A
I
think
the
the
issue
is
that,
as
these
libraries
are
adding
things,
natively,
they're
kind
of
adding
like
options
to
like
opt-in-
I
guess
the
instrumentation
and
the
the
conversation
was
that
this
is
getting.
This
is
going.
This
is
getting
a
little
complex
and
it's
also
going
to
only
get
worse
if
more
frameworks
add
instrumentation
and
kind
of
add
their
own
ways
to
opt-in.
So
I
think
the
the
ask
here
was
for
open
telemetry
to
provide
guidance
to
kind
of
first-party
instrumentation,
and
I
think.
A
A
So
I
think
these
three
bullet
point
issues
are
kind
of
the
proposed
response,
but
yeah,
basically
the
natively
instrumented
component
should
not
have
you
turn
on
open,
telemetry.
E
Is
the
assumption
here
that
components
is
referring
just
to
natively
instrumented
components,
or
should
this
also
be
done
for
the
auto
instrumentation
that
we're
writing.
A
I
think
it's
a
good
question
and
I
think
it
should
probably
apply
universally
and
I
guess.
A
I
think
with
our
instrumentation
are
we
always
assuming
the.
E
We
are
always
assuming
the
global
provider.
I
feel,
like
a
question,
came
up
last
week
or
the
week
before
about
this,
and
there
was
some
circumstance
where
somebody
might
want
to
pass
in
a
tracer
provider.
It
might
have
been
ariel.
That
was
asking
a
somewhat
hypothetical
question
at
the
time,
but
maybe
it's
less
hypothetical.
Now.
C
C
This
does
kind
of
interestingly
sort
of
dovetail
with
the
instrumentation
api
proposal
that
has
been
kicked
around
over
in
the
otp
plan.
I
think
I'm
not
sure
if
it's
precisely
all
the
same,
but
oh
it
kind
of
feels
the
same.
A
So
I
think
we
have
had
this
discussion
before
maybe
even
like
way
way
way
back.
I
think
when
we
first
started
when
we
first
started
adding
instrumentation
and
kind
of
had
implemented
the
what
is
now
instrumentation-based
class,
and
I
think
this
would
be
pretty
easy
to
address
at
the
instrumentation
base
level.
As
long
as
we
had,
I
think
the
harder
part
is
just
like
figuring
out
how
to
pass
the
thing
in,
but
I
think
that
would
be
like
a
fairly
easy
place
to
kind
of
store.
The
state.
C
A
C
If,
if
we,
if
we
showed
how
we
addressed
this
with
instrumentation
base,
actually,
if
we
did
address
it
and
show
how
it
could
be
used,
I
think
it
could
be
a
really
sort
of
continuingly
useful
counterpoint
to
some
of
the
things
we
didn't
care
for
in
the
instrumentation
api
proposal,
to
show
how
you
can
pass
this
configuration
around
in,
like
a
really
standard,
well-defined
way,
without
also
imposing
a
lot
of
other
things
on
instrumentation
like.
F
E
Yeah
we
had
a
discussion
or
an
issue
not
long
ago,
where
we
wanted
to
maybe
factor
out
common
configuration
options
for
different
types
of
instrumentation.
E
So
the
trying
to
think
the
database
obfuscation
stuff,
like
the
db
statement,
obfuscation
option
was
something
that
you
might
want
to
factor
out
so
that
it
behaved
in
the
same
way
for
all
database
instrumentation.
And
if
we
come
up
with
a
way
of
solving
that,
then
that
should
also
work
for
this
case
with
instrumentation
base.
E
Where,
like
the
tracer
provider,
is
a
common
configuration
option.
A
E
Yeah
sure
yeah
it's
outside
of
the
scope
of
1.0.
It
doesn't
affect
the
1.0
release,
but
yeah.
We
can
definitely
go
ahead
and
do
that.
A
I
think,
ultimately,
like
things
were
pretty
early
on
and
the
sentiment
was
kind
of
yagny
and
we'll
add
it
when
we
need
it
once
once
we
find
a
use
case
for
it.
We
will
add
it,
so
I
don't
think
there
was
like
a
like
strong
opposition
to
it,
which
is
kind
of
let's,
let's
see
if
we
need
it.
First.
C
Yeah,
hey
matt.
I
had
a
question
just
from
since
you
were
in
the
spec
sig
meeting,
and
I
wanted
to
know
like
your
take
on
this.
Do
you
get
the
sense
that
this
sort
of
thing
being
able
to
need
to
set
a
provider
instead
of
using
the
global
one,
is
sort
of
a
language
specific
thing
like
based
on
the
way
that
different
languages
historically
implemented
observability
within
themselves,
because
I
I
think
about
it
in
in
the
ruby
world
and
I'm
sort
of
just
like?
C
Why
do
you
need
to
pass
a
different
tracer
provider
to
one
part
of
your
application,
as
opposed
to
another
one,
and
we
haven't
come
up
with
great
reasons
yet,
but
I'm
wondering
if
maybe
that's
just
kind
of
historically
how
things
were
done
like
with
java,
and
you
know,
creating
multiple
loggers
one
for
each
class.
That
sort
of
thing
is
that
I
guess
like
do
you
get
a
sense
of
like
maybe
where
this
is
coming
from,
like
what
makes
it
necessary.
A
I
I
have
long
raged
against
the
multiple
tracer
provider
kind
of
caveatting
in
in
the
spec,
because
it
is
something
that
I
think
is.
A
It
something
that
I
haven't
really
seen
used,
I
guess
in
a
movie
and
and
something
that
I
think
that
we
ever
really
would
use,
but
like
there
is
kind
of
like
this
core,
I
guess
there
is
there.
Is
this
desire,
I
guess,
to
be
able
to
have
a
single
application
generate
spans
for
really
like
more
than
one
resource.
I
think
is
the
way
that
I
would
say
that
so,
like
resources
tend
to
be
static
or
they
should
be
a
static
thing.
A
They're
attached
at
the
tracer
provider
level,
and
I've
heard
that,
like
there
are
some
like
java,
some
historical,
older
java
frameworks
or
some
instrumentation
that
was
happening
in
java
at
one
point
in
time.
That
kind
of,
I
think,
was
the
thing
that
spurred
all
of
this,
but
it
has
led
to
like
so
many
weird
things
that
you
have
to
keep
track
of
in
the
implementation
that,
unless
you,
unless
you
know
about
this,
you
would
probably
not
implement
things
this
way.
A
So,
like
one
one
of
the
things
that
we're
left
with
today
is
you
kind
of
have
to
have
the
the
resource
has
to
be
on
every
single
span
or
on
every
metric
that's
generated,
and
then
your
exporter
needs
to
group
by
span
or
group
by
resource
to
be
able
to
send
things
out
and
that's
kind
of
an
artifact
of
this.
Because
technically
you
can
have
multiple
tracer
providers,
they
could
share
an
exporter
and
all
these
other
disappeared
things
that
you
have
to
keep
in
mind.
I.
E
Think
the
spec
actually
says
that-
or
there
was
some
confusion
around
this,
and
the
decision
was
made
that
tracer
provide
each
tracer
provider
should
have
its
own
exporter
effectively
yeah.
So
you
shouldn't
be
sharing
like
the
span,
processor
and
exporters
between
tracer
providers,
but
yeah.
It's
it's
a
messy
part
of
the
spec
we
robert
and
I
were
looking
at
something
this
morning
where
we
want
to
trace
the
trace
export
pipeline,
because
why
wouldn't
you
and
but
like
our
customers,
I
guess
so.
E
Service
owners
within
shopify
get
irritated
when
they
search
for
traces
and
they
just
see
traces
for
otlp
export
from
their
service.
So
we're
sticking
that
into
a
different
environment,
and
all
we
can
do
right
now
is
stick
an
environment
tag
on,
but
arguably
you
could
use
a
tracer
provider
with
its
own
resource
just
for
tracing
the
export
pipeline
and
give
that
a
different
deployment,
dot
environment.
E
So
that's
a
potential
use
for
different
tracer
providers.
The
challenge
there
is
that
you're,
like
you're,
using
a
common
set
of
instrumentation-
and
I
don't
know
if
you
can
like
not-
I
don't
know
you
the
way-
we've
designed
the
instrumentation.
You
can't
really
plug
in
the
same
instrumentation,
twice
with
different
tracer
providers,
which
you'd
kind
of
have
to
do
for
this
use
case,
because
you'd
want
your
http
spans
from
the
export
calls
to
actually
use
a
different
tracer
provider
from
all
the
other
http
spans
that
are
generated
within
your
application.
E
So
yeah
practically
speaking,
I
don't
know
how
auto
instrumentation
or
really
native
instrumentation
in
various
components
would
be
able
to
leverage
this
like
leverage
different
trace
providers.
C
C
Like
makes
sense
as
to
how
this
could
be
useful
and
like
why
it's
useful
in
other
places-
and
I
was
thank
you
for
sharing
it,
because
I
like,
as
I
engage
with
people
about
other
proposals
and
stuff,
you
know
having
that
context
of
why
this
is
important.
For
some
ecosystems,
like
that's,
that's
just
good
to
have,
it
makes
sense.
A
So
I
will
mention
I
stopped
raging
against
this
actually
and
the
reason
why
the
thing
that
calmed
me
down
was
that,
like
what
francis
was
just
saying
where
you're
sharing
instrumentation-
and
this
was
like
the
thing
that
was
like
really
bothering
me
is
like
you-
can't
really
have
multiple
tracer
providers
that
share
the
same
instrumentation,
and
if
you
wanted
to
have
something
like
that,
maybe
you
would
need
something
like
a
tracer
provider
provider,
and
that
was
all
just
made
me
feel
generally
unhappy.
But
the
thing
that
I
was
thinking
was
like.
A
Okay,
I
think
there
is
this
use
case.
I
do
think
that
it's
like
underdeveloped
and
the
way
that
I
would
see
it
actually
working
and
possibly
working
well-
is
to
be
able
to
manage
this
at
the
context
level
and
to
be
able
to
kind
of
have
like
a
block
where
you
say
here
are
some
additional
resource
related,
or
this
is
attached
to
this
resource.
A
Being
able
to
you
know
if
your
resource
needs
to
be
static
or
whatever
you
could
establish
those
in
the
beginning,
but
have
have
ways
to
scope,
different
work
to
resources
and
then
have
your
instrumentation.
Be
able
to
pick
up
what
is
the
appropriate
resource
to
attach
via
the
context,
and
I
think
things
would
work
out.
E
Yeah
but
then
what
happens
when
somebody
from
a
different
thread
wants
to
access
like
your
threads
context,
I
don't
know
why
anybody
would
want
to
do
that.
I
would.
E
D
I
I've
got
my
usual
sort
of.
I
feel
dumb
question
to
see.
If
I
understand
the
situation,
is
this
a?
I
want
a
tracer
provider
mostly
because
I
want
to
set
resource
attributes
within
with
I
don't
I'm
wary
of
using
the
word
context
within
this
use
case,
I
would
like
these
resource
attributes
on
all
spans.
E
E
Yeah
but
deployment
environment
is
one
of
those
kind
of
slightly
wishy-washy
things
right
in
the
sense
that
deployment
environment
could
mean
different
things
depending
on
the
environment,
so
you
could
have
a
staging
cluster
that
act
or
you
could
have
a
production
cluster
that
had
staging
deployments
in
it.
So
in
that
case,
what
is
the
environment?
E
And
then
you
can
also
have
these
weird
use
cases
where,
because
of
the
tooling
that
you're
using
to
view
this
and
limitations
of
the
tooling
that
you're
using
to
view
your
traces,
you
may
want
to
effectively
segregate
certain
traces
and
not
have
them
visible
to
certain
users
most
of
the
time,
so
most
application
owners
don't
care
about
the
trace
export
pipeline.
E
They
don't
care
about
seeing
that
connection
on
their
service
graph,
but
the
folks
who
are
managing
the
tracing
infrastructure,
like
you
know,
say
rob.
For
example,
sorry,
robert,
not
not
you,
but
anyway
you
get
it.
E
So
folks
like
that,
would
typically
want
to
see
a
service
graph
that
shows
the
trace
export
pipeline
and
not
necessarily
what
the
applications
are
doing
right
right.
The
application
owners
don't
care
about
the
trace
pipeline
until
their
tracing's
broken
exactly
exactly,
but
then
then
they
might
so
being
able
to
segregate
that
by,
like
it's,
an
abusive
deployment
environment,
but
it's
an
abuse
that
actually
works
reasonably
well
right.
So
that's
that's
a
potential,
but.
D
C
D
Precise
words,
I
think,
right
because
resource
attributes
are
the
thing
that
says
I
want.
I
want
this
attribute
on
all
of
these
spans
we're
trying
to
reach
for
that
to
solve
this
problem.
G
A
I
don't
know
a
summary
of
how
yeah
how
things
are
set
up
kind
of
some
of
the
things
people
want
out
of
it,
and
some
of
the
weird
reasons
why
it
is
the
way
it
is.
A
Sounds
like
yes,
so
we'll
go
ahead
and
move
on
to
this
issue.
We
talked
about
it
last
week.
Briefly,
it
was
kind
of
just
to
add
an
option
to
limit
the
the
length
of
attribute
values
and
metric
values,
and
I
think
it's
people
are
still.
The
general
idea
is
fine.
I
think
josh
mcdonald
had
some
reasonable
comments
here.
A
He
he
was
at
least
mentioning
that
should
be
careful
with
logging,
because
since
the
saying
that
a
log
should
be
emitted
to
indicate
that
an
attribute
was
truncated
too
big,
something
like
that-
and
I
think
his
concern
was
just
like
just
make
sure
that
you're
not
blowing
up
the
logs.
This
is
happening.
A
lot
which
I
think
is
a
valid
concern.
E
Yeah
there
was
a
requirement,
or
there
is
a
requirement
in
the
spec
that
implementations
should
limit
the
amount
of
logging.
They
do
per
kind
of
error
scenario
specifically
around
attribute
limits,
so
we're
not
doing
that
right
now.
E
It's
probably
something
we
should
consider
doing.
I
don't
like.
I
don't.
I
think
most
of
the
limits
should
apply
per
like
span
name
and
key
pair,
not
including
the
value
right,
because
if
you
think
the
value
is
potentially
really
high
cardinality,
so
you
could
end.
You
know
if
you're
trying
to
say
only
one
log
once
per
like
span
key
value.
E
Triplet
then
you're
gonna
have
to
record
that
somewhere
and
that's
potentially
quite
large.
So
anyway,
it's
something
we're
not
doing
right
now
we're
somewhat
verbose
in
our
logging.
If
somebody
messes
up
a
an
attribute
value,
for
example,
we're
just
going
to
be
logging
that
throughout
the
lifetime
of
their
application,
so.
A
A
I
think
it
does
make
sense
someday,
as
we
get
more
sophisticated
to
kind
of
have
this
log,
once
functionality
and
kind
of
be
able
to
derive
like
a
a
reasonable,
a
reasonable
key
and
kind
of
that
scheme
that
you
were
just
mentioning
stand,
name,
attribute,
name
value
or
at
least.
E
So
what
sorry.
B
That's
gonna
say
one
of
the
things
we
are
doing
like
for
when
we
validate
like
attributes
on
spam.
We
do
kind
of
just
finally
log
the
message
as
an
error,
but
because
we're
the
logs
are
going
through.
The
error
handler
like
there
is
an
escape
patch
for,
like
application
owners
to
supply
their
own
error
handler
to
sample
error
messages,
and
they
can
match
against
it's
a
lot
more
hands-on,
but
at
least
it's
not
impossible
for
someone
to
get
that
functionality.
E
Yeah,
the
spec
is
just
suggesting
that
the
sdk
should
be
providing
that
functionality.
So
we're
not
right
now,
one
of
the
interesting
things
about
this.
This
pr
is
that
it's
actually
providing
this
kind
of.
E
I
want
to
say
generalization,
so
you
can
just
set
one
attribute.
Sorry,
I'm
just
trying
to
find
the
thing
again,
but
there
was
just
like
one
attribute
value
limit.
Yeah
hotel
attribute
value
length
limit
that
that
would
then
be
kind
of
an
attribute
length
limit.
That
applies
to
event,
attributes,
link,
attributes,
span,
attributes
and
then
you'd
have.
E
G
A
I
feel
like
this
was
just
a
clarification
that
you
that
one
of
the
protobuf
variations
of
the
protocol
of
otlp
should
be
supported
by
a
by.
H
A
A
If
ever
people
started
talking
about,
must
support
votes?
What
would
our
opinion
be.
E
We
should
do
this
like
we
should
add
the
grpc
support
we
we
just
haven't
yet
mostly
because
I
don't
know,
there's
a
a
reasonable
fear
of
grpc.
C
I
think
we
we're
sort
of
whether
or
not
we
like
protobuf
is
a
problem
in
and
of
itself,
but
we
already
have
the
dependency
on
it
today.
We'd
be
then
taking
you
know
a
dependency
on
the
grpc
libraries
and
those
are
just
a
different
level
of
annoying.
Like
you
know,
protobuf
is
almost
I
hate
to
use
this
word
but
orthogonal
to
to
it.
I
will
say
like
having
dove
into
the
the
grpc
official
client
libraries
for
ruby.
I
think
we
could
implement
this
and
it
wouldn't
be
miserable.
C
E
Yeah
there's
some
fear
and
scarring.
I
guess
around
the
use
of
grpc
in
pre-forking
web
servers
and
the
fun
that
connects
you
when
you
basically
trigger
a
fork
bomb
anyway.
It
it's
just
not
fun.
We
have
filled
volumes
at
google
with
core
files
as
a
result
of
this
and
had
a
major
disruption
so
yeah
we
we
just
have
those
battle
scars
and
we're
somewhat
timid
to
actually
do
anything
with
grpc,
but
we
should
do
it
and
potentially
place
big
warnings
around.
E
D
E
D
E
You
know
what
nope
it's
out
of
my
head.
I
can't
remember
it
either
yeah,
so
I
think
we
want
separate
gems,
because
that
way,
you
don't
have
to
take
a
grpc
dependency.
If
you
don't
need
it
so
having
the
separate
gems
is
the
best
way
to
achieve.
A
A
A
Basically,
people
end
up
wrapping
like
bundling
up
wrapping
open,
telemetry
components
so
and
when
you
send
stuff
to
tracing
back
ends
with
like
an
otlp
exporter,
they
all
look
the
same
because
you
may
or
may
not
have
added
an
attribute
to
kind
of
indicate
that
it
is
like
this
custom
bundle
or
distribution.
A
G
G
D
In
our
distro
we've,
I
know
we've
added
something
to
this
cluster
of
resource
attributes.
I
don't
know
if
we
overrode
something.
I
think
we
kept
the
original
that
we
were
distributing
from,
so
that
you
can
see
the
upstream
open,
telemetry
stuff,
but
yes,
something
consistent.
That
would
say
so.
Your
distribution.
E
A
Yeah
and
it
would
be
useful
to
know
if,
if,
if
your
service
teams
are
using
your
rapper
gem
or
going
rogue
and
at
least
being
able
to
figure
that
out
in
a
standard.
A
Way
so
there
was
this
fairly
long
and
interesting
conversation
around
scraping
support
for
tracing
data,
so
it's
basically
kind
of
the
prometheus
model,
but
for
tracing
data.
Where
you
could,
I
think
I
think
the
person
who
brought
this
up
maybe
is
involved
with
spring
boot
and
I
think
spring
boot
was
considering
adding
this
functionality
and
if
there
was
a
way
to
kind
of
get
tracing
data
out
of
a
spring
boot
application
in
an
otlp
format.
A
A
Yeah,
so
the
summary
of
the
conversation
is
that
this
that
the
prometheus
model
works
pretty
well
for
metrics,
because
things
kind
of
like
roll
up
and
like
you're,
not
so
dependent
on,
like
a
scrape
interval
like
you,
can
have
kind
of
as
long
of
a
scrape
interval
as
you
want
and
you're
not
really
going
to
miss
anything
because
you're
just
going
to
get
like
a
little
bit
less
resolution
on
your
metrics,
but
all
of
the
data
will
kind
of
still
be
there
in
some
way,
whereas,
like
tracing
data,
you
do
need
to
kind
of
like
get
this
regularly
or
purge
it
regularly.
A
You
can't
probably
keep
it
here
indefinitely,
so
the
discussion
then
kind
of
turned
like,
but
if
you
could
kind
of
like
make
this
a
stream
that
you
can
subscribe
to
our
http,
so
it
could
be
like
a
server-side
events
or
some
other.
I
don't
know
http
2.
I
suppose.
A
Endpoint
that
you
could
just
dial
into
to
get
tracing
data
streamed
out
of
the
app.
It
would
be
interesting
for
coming
back
to
kind
of,
like
this
whole
notion
of
of
resources.
A
It
at
least
be
able
to
like
invert
the
the
identifying
a
resource
kind
of
scheme
so
rather
than
an
application
telling
you
it's
identity,
like
the
scraper,
could
kind
of
know
the
identity
of
the
thing
it's
going
to
expand
from,
because
it
had
to
know
the
identity
of
it
in
order
to
to
dial.
A
A
I
think
kind
of
yeah,
it
seems
like
there
is
a
way
to.
A
A
That
came
out
of
this,
but
ultimately
I
don't
think
I
don't
think
the
ask
is
that
sdk
would
provide
this
functionality.
It
was
kind
of
a
thing.
I
think
that
spring
boot
was
looking
to
add
and
asking
like
if
they
added
it
would
open
telemetry
do
something
with
the
collector
for
it,
and
I
think
the
answer
was
most
likely.
C
It's
definitely
interesting,
I
mean
I
could
see
that
being
a
really
great
use
case
for,
like
the
contrib
collector
and
having
a
way
to
pull
that
out,
I
mean
I
I
personally
have
just
givings
about
the
prometheus
breaking
model
in
general,
but,
like
I
it's
interesting,
I
I
think
if
the
resource
problem
is
actually
what
it
solves
very
well,
but
that's
intriguing.
I've
never
thought
about
pulling
spam
data
like
that
in
a
way.
A
G
A
Yeah-
and
I
think
that
was
my
other
thought-
it
was
like
this
is
interesting,
but
is
it
useful
and
where
is
it
useful.
A
A
But
yeah,
if
if
this
does
make
it
in
and
it
is
interesting
and
useful
and
in
other
ways
there
will
at
least
be
a
way
to
wire
up
a
collector
with
something
that
wants
to
kind
of
implement.
One
of
these
publishing.
A
H
So
I
think
sas
one
was.
A
Similar
to
everyone
should
have
a
grpc
implementation.
I
think
it
was
an
asset.
Everybody
should
also
implement
one
of
the
http
one
of
the
something
over
http
versions
of
otlp,
so
either
photo
over
http
or
json
or.
A
Http,
what
it's
worth
I
think
json
over
http,
is
still
like
considered
experimental
by
the
stack
which,
which
is
a
pretty
big
problem.
If
you
want
to
use
fans
out
of
a
browser,
I
bring
that
up
every
now
and
then
but
there's
there's
reluctance.
I
think
from
the
collector
sig
to
or
I
don't
know,
if
that's
the
exact
group
of
people
to
to
sailors
reluctant
but
there's
just
some
general
reluctance
around
it.
A
I
think,
because
of
it's
very
committing
once
you
establish
the
json,
the
format
of
the
json
messages,
they're
harder
to
change,
they're
kind
of
impossible
to
change,
whereas
with
protobuf
it's
like
you
have
you
have
a
number
of
changes
that
you
can
make
that
will
still
be
backwards
compatible.
A
I
So
one
item
that
was
not
here
and.
A
Yeah,
this
is
going
a
little
long
today.
Sorry,
oh
one
of
them-
that's
not
here,
but
maybe
somewhat
important,
is
that
there
is
the
asia
pacific
version
of
this
meeting
which
nobody
ever
goes
to.
But
apparently
that
was
happening
bi-weekly.
They
have
moved
it
to
a
weekly
cadence
and
it
seems
like
a
lot
of
the
oh.
It
seems
like
they're
talking
a
lot
about
the
instrumentation
api
improvements
and
maybe
even
the
convenience
method
apis.
A
So
one
of
the
things
specifically
those
brought
up
when
they
were
plugging
the
the
4pm
pacific
version
of
this
meeting
is
that.
A
Kind
of
having
a
way
to
have
callbacks
for
the
end
of
your
span
to
do
things
like
record,
metrics
and
and
other
things
so
that
scheme-
I
think
we
touched
on
that
last
week,
so
I
will
probably
not
be
going
to
that
4pm
meeting
unless,
for
some
reason
I
just
feel
like.
I
have
an
abundance
of
free
time,
but
if
anybody
does
want
to
go
there,
I
do
think
it
would
be
interesting
if
you
have
to
have
an
abundance
of
free
time
at
4
pm,
pacific.
C
I
don't
know
that
I
would
say
I
have
an
abundance
of
free
time
necessarily,
but
if
that's
where
they're
discussing
the
instrumentation
api
and
things
like,
I
have
a
lot
of
strong
opinions
on
that.
So
I
might
actually
make
a
point
to
attend
it's
every
week
on.
Is
it
today
at
4
p.m?
Pacific!
C
A
A
All
right,
so
maybe
we
should
take
a
look
at
our
repo
before
we
run
out
of
time.
A
I
see
we
have
a
handful
requests.
I
see
andrew
was
mentioning
that
he
might
not
make
it
today,
but
did
and
would
bring
up
that
he
opened
the
prs
and
awaits
our
judgment.
C
That
was
that
was
correct.
Yes,
the
waiting
judgment
I
didn't
have
much
to
contribute
other
than
like
they're
there,
probably
the
most
interesting
part
of
it
was
I
opened
the
pr
for
the
auto
generation
of
the
constants
from
yemel,
and
I
mean
there's
where
we
should
stick
them
where,
in
the
name
spacing
is
something
that
I
actually
not
sure
about,
and
I
felt
like
perhaps
people
would
have
strong
opinions
on
and
I
would
be
happy
to
receive
those
opinions
if
you
have
them.
E
I
think
I
approved
that
and
robert
approved
that
we
both
thought
it
was
awesome
and
we
went
ahead
and
merged
it.
So,
oh.
C
A
That's
fine.
You
still
have
prs.
I
think
two
of
them
are
are
draft
so
probably
interesting
for
folks
to
look
at
if.
C
E
Are
we
still
waiting
yeah?
So
we,
the
status
of
that
was
it
looks.
Fine
to
me,
looks
fine
to
robert.
I
think
rob
had
some
issues
with
it
earlier.
You
were
going
back
and
forth.
I
guess
with
andrew
over
that
yeah.
D
I
had
two
apps
one
was
having
issues
and
the
other.
Doesn't
I'm
still
trying
to
replicate
that
problem,
I'm
also
willing
to
chalk
up
the
the
one
time
I
was
having
issues
as
user
error.
If
other
people
are
using
this
successfully.
E
C
D
Would
not
call
my
my
experiments
production
either.
They
were
just
the
the
toys
that
we
have
as
examples
for
instrumenting
things.
I
instrumented
with
this
branch
and.
C
Yeah,
that's
the
same
way.
I
had
done
it
really
I'll,
say
this
I'll.
What
I
will
do
is
so
github
is
off
this
week,
but
I
will
install
this
in
one
of
our
sort
of
main
testbed
applications
that
is
in
production
and
then,
if
nothing
blows
up
there,
then
we
can
say
it's
probably
good,
and
if
we
have
more
errors
where
people
are
unable
to
get
it
installed
because
of
the
way
you
know
rails,
initializes
itself
or
whatever
we
could.
A
Pr
to
open
up
or
apr
open
to
update
otlp
to
the
latest
protos
is
this.
E
Yeah,
I
was
slightly
cranky
about
this,
probably
because
I
just
had
a
rough
night
the
night
before,
but
the
yeah
may
may
you
sort
of
mild
irritation.
I
guess
was
just
I
had
been
planning
to
do
this
like
we
don't
actually
need
anything
from
it
yet
from
the
update.
The
largest
portion
of
it
relates
to
metrics,
which
we
don't
have
an
implement
implementation
for
yet
the
only
thing
that
happened
was
the
status
code
change
which
we
need
to
implement
by
october
anyway.
E
E
Before,
like
we
do
have
integration
tests
right
that
need
to
be
run
locally,
they
can't
be
running
ci
for
oglp.
So
I'd
like
to
try
that
out
before
we
give
the
thumbs
up
to
this
pr
and
merge
it
just
because
like
it
does
have
potential
to
break
things
and
I'd
rather
catch
that
early.
A
Yeah,
no,
it's
fine!
I
didn't
realize
that
there
was
more
that
most
of
the
conversation
was
actually
happening
on
the
issue
and
not
not
the
pr.
It
seems.
D
But
so
this
is,
this
is
one
of
my
co-workers
at
honeycomb
submitting
it
just
because
we've
been
doing
some
work
with
ruby.
I
totally
appreciate
wanting
integration
tests
on
stuff.
Since
you
know,
enums
have
changed
so
you
want
to
make
sure
that
nothing
blows
up
eyeballing
it.
D
I
think,
on
the
wire,
the
numbers,
the
new
names
for
the
enum,
still
line
up
to
the
same
digits
integers
passed
on
the
wire,
so
I
suspect
it's
okay,
but
you
know
totally
appreciate
that
it
takes
time
to
confirm
that
things
like
this
don't
break
stuff.
E
D
I
think
we're
mostly
seeing
data
sent
with
the
current
hotel,
ruby
libraries
that
that
a
lot
of
times
the
span
status
is
unset,
for
whatever
reason
I
haven't
traced.
Why?
But
the
vast
majority
of
the
traces
we
get
from
ruby
are
spam
status
on
set,
and
it
could
be
that
just
nobody's
looking
using
that
attribute
for
reasons
they
care
about
other
attributes
in
the
span.
E
D
D
So
again,
I
I'm
cautiously
optimistic
that
the
integration
tests
that
are
absolutely
necessary
to
be
run
we'll
should
show
that
this
is
good,
but
yeah
yeah.
You.
E
Can
you
can
run
the
integration
test
locally,
there's
just
an
environment
variable
you
have
to
set
okay
in
order
to
figure
that.
F
F
E
And
set
the
environment
variable
and
then
just
run
the.
E
D
E
D
I
know
it
was
I
I
think
it
was
tick
in
the
box
to
keep
things
up
to
date
with
specs.
Okay.
No,
we
don't
need
metrics,
yet
we're
inclined
to
tell
people
not
to
do
metrics.
E
D
E
Yeah
a
lot
of
my
caution
right
now
is
that,
like
we
are
rolling
this
out
widely
in
production
at
shopify,
and
I
don't
want
it
to
start
blowing.
D
E
Goes
from
zero,
four
zero
to
zero
five
zero
and
then
all
the
rest
of
it
is
just
metrics
which
doesn't
impact
anything
else.
D
E
A
Yeah,
I
could
also
vouch
that
mike
is
a
good
person.
I
worked
with
him
for
a
short
time.
Tell
him
hi
by
the
way
so,
but
I
can
also
vouch
that,
like
double
checking
this
fan
status,
stuff
is
a
good
idea
like
there
was
at
least
one
bug
that
that
we
encountered
when
this
lights
up.
When
this
change
was
introduced.
A
I
think
it
mainly
had
to
do
with
our
json
ingestion,
because
json
messages
are
a
lot
more
harder
to
change
than
the
protobuf,
as
we
talked
about
a
little
earlier,
but
but
yeah,
just
just
verifying
that
your
tracing
backhand
has
handled
this
properly
is
a
is
a
good
idea.
A
We
are
down
to
two
minutes.
I
do
have
a
hard
stop,
so
feel
free
to
continue
without
me.
If
I
do
have
to
drive
off,
but
is
there
anything
that
we
should
get
started
as
a
topic.
G
I
just
want
to
say
I
am
doing
the
things
I
am
assigned
in
the
open
issues.
It's
been
a
month,
that's
my
which,
for
me
is
a
reasonable
time.
No,
I,
but
I
I
recognize
that
it's
blocking
starting
to
block,
but
I
have
time
scheduled
to
do
it.
Then
they
don't
get
done.
That's
awesome.
E
E
Yeah,
I
don't
know
like
we.
You
know
robert
enjoys
a
ceremony
of
saying.
Oh,
a
new
person
is
being
added
to
this.
I
I
like
to
be
informed
but
yeah
I
don't
know
again
like
this,
was
also
my
day
where
I
had
a
shitty
night.
So.