►
From YouTube: 2021-06-08 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).
C
You
see
that
we
have
christopher,
I'm
not
sure
if
you've
been
around
before
that's
my
first
one
martin.
This
is
my
first.
This
is
my
first
one
which
one
okay.
B
Welcome
thank.
C
You
so
yeah
we
do
have
an
agenda
doc,
so
I'm
not
sure
if,
if
anybody
does
have
any
printing
questions,
but
if
so
feel
free
to
ask
them
feel
free
to
drop
them
in
this
dock,
I
think
the
the
plan
probably
is
to
run
through
the
spec
sig,
hopefully
fairly
quickly.
We
can
start
looking
through
issues,
pull
requests,
and
then
francis
mentioned
in
slack
that
we
have
a
ga
1.0
milestone
that
could
probably
use
some
triaging
yeah.
We
should
also
talk
about
the
issues
that
are
found.
C
I
know
francis
mentioned
that
there
are
some.
I
don't
know
if
they're
documented
anywhere
so.
C
Let's
go
through
the
spec,
stick,
really
quick
and
then
move
on
to
our
repo
and
I'll
ask
for
where
we
should
start.
We
start
with
the
most
important
stuff.
First.
C
There
are
environment
variables
to
configure
your
endpoint
for
export,
and
I
think
this
is
specifically
for
the
collector
exporter,
and
I
think
the
core
issue
here
is
that
we
have
been
trying
to
use
like
one
set
of
configuration
for
both
grpc
and
then
http
transport,
and
I
think
http
users
find
the
grpc
options
weird
and
then
grpc
users
are
finding
the
http
options
weird.
C
So
I
think
finally,
somebody
has
decided
we
just
need
to
split
these.
We
need
to
have
slightly
different
options
for
http
versus
trpc.
C
I
think
the
most
controversial
part
of
this-
or
I
think
the
key
part
of
this-
is
this
insecure
bit.
We
have
switches
using
schemed,
urls,
and
the
scheme
of
the
url
should
identify
the
secureness
of
the
connection,
but
for
some
reason
this
is
not
working
for
everybody.
C
I'm
not
sure
exactly
what
this
means,
but
it
does
sound
like
there
will
be
an
o
coming
to
tell
us
how
to
handle
that
situation.
So
I
think
the
idea
is
if
some
of
the
data
is
good.
Hopefully
it
can
be
exported
and
there's
a
way
to
communicate
that
back
to
the.
C
B
C
I
think
there
is
some
discussion
around
retry,
but
I'm
not
sure
that
this
is
ever
yeah
retry
logic
for
otlp
exporters.
There's
some
spec
language
around
it.
I
don't
know
that
it's
ever
been
super
well
defined.
A
I
think
in
our
implementation
we
already
have
like
retrieve
implemented
for
the
export
right,
so.
C
Yeah
so
hopefully
what
we're
doing
is
generally
spec
compliant.
C
Well,
I
guess
the
conversation
that
came
up
here
is
somewhat
interesting
in
that
there
are
semantic
conventions,
they're
like
layers
of
semantic
conventions,
so
like
there's
kind
of
like
the
resource
level,
which
generally
are-
and
this
is
also
super
contentious-
and
we
ended
up
talking
about
this-
a
little
bit
more
later
at
the
meeting
as
to
like
what
actually
are
the
resource
attributes.
C
But
originally
the
idea
is:
these
are
the
things
that
describe
the
process
kind
of
like
the
kind
of
like
fixed
attributes
for
the
duration
of
a
running
process,
more
or
less
how
fixed
they
are
is
also
like
a
topic
of
debate.
That's
what
he
kind
of
came
up
to.
There's
like
right
now,
they're
kind
of
supposed
to
be
all
set
in
stone
very
early
on
in
the
application.
It
becomes
very
hard
to
modify
them
later.
C
There
are
some
desires
to
change
that
because
it
makes
it
makes
things
hard
for
things
like
resource
discovery,
etc.
But
that's
not
this
topic.
This
topic
is
actually
so
at
the
resource
level,
we
have
a
series
of
semantic
conventions
and
then
kind
of
at
the
span
level.
So
if
you're
tracing
data
we
have
semantic
conventions
and
then
for
metrics,
you
also
have
semantic
conventions
and
it
turns
out
that
there
is
some
overlap,
sometimes
between
these
different
buckets
of
attributes
and
like
in
the
best
case.
C
C
There
was
no
answer
to
this
right
now
other
than
we
need
to
think
about
this.
A
little
bit
more.
I
think.
C
Then
yeah,
I
was
kind
of
the
other
thing
that
I
was
alluding
to
was:
what's
the
status
on
resource
immutability
that
came
up
a
little
bit
later.
D
Does
this
this
is
just
for
inside
of
the
collector,
how
it's
represented
internally
or
is
it
will
it
have
effects
outside
of
the
collector
as
well?
D
F
D
C
Yeah,
I
think,
having
not
read
the
full
document
myself,
I'm
not
sure
what
to
say
other
than
that.
It's
interesting
it
does
seem
like
it's
a
fairly
detailed
document
yeah.
I
guess
just
looking
at
the
table
of
contents
that
there
is
a
future
possibility
of
a
native
otop
implementation.
C
So,
like
otlp,
being
kind
of
the
the
protocol
for
exchanging
or
sending
telemetry
data
to
a
back
end
would
mean.
I
guess
that
this
would
extend
beyond
the
collector,
so
anybody
consuming
otlp
would
be
able
to
use
this
format,
and
I
suppose
it
would
mean
that,
like
whatever
we're
modeling
our
telemetry,
however
we're
modeling
our
telemetry
today
we
would
have
some
new
new
way
to
structure.
E
Some
of
it,
so
it's
it's
in
an
entity
model
within
the
collector,
we're
talking
about
possibly
changing
the
shape
of
otlp
like
the
spec.
That
is,
here's
how
you
describe
things
like
it'll
affect
the
shape
of
the
protobufs
that
we're
all
using
to
generate
possibly.
D
Like
if
they,
if
they
find
some
learnings
from
this
unification
inside
the
collector
and
representing
the
data
this
way,
maybe
they
will
perhaps
uncover
a
better,
more
efficient
or
more
useful
method
of
representing
things
that
would
then
propagate
back
towards
otlt.
This
may
be
what
I,
how
I
read
that,
but
I'm
not
I'm
not
sure.
C
B
D
C
C
Basically
so
yeah
carlos
has
this
title
related
to
recent
work
in
the
sampler
receiving
the
resource.
So
there
is
a
sampling
working
group.
I
think
that's
going
to
start
back
up
one
of
the
things
that
we're
talking
about
that
is
having
the
sampler,
maybe
explicitly
get
a
resource,
not
exactly
sure.
C
If
I
have
that
right
or
not-
but
I
do
kind
of
remember
this
issue,
and
basically
there's
this
idea-
that
your
that
a
tracer's
provider
at
tracer
provider,
initialization
time,
you
should
have
a
resource
that
you
should
you
can
pass
to
it
and
that
resource
should
be
kind
of
like
fully
realized
at
that
point
in
time.
So
it
resources
are
supposed
to
be
immutable
so,
like
once,
you
instantiate
a
tracer
provider.
C
That
resource
should
remain
static
from
from
there
on
out
and
basically
the
way
that
you
get
your
resource
to
the
export
pipeline
is
that
the
tracer
provider
will
put
the
resource
on
each
span
individually
and
then
your
exporter
will
kind
of
group
stands
by
resource.
C
It's
a
crazy
system
and
a
lot
of
people
have
been
confused
by
this,
and
the
reason
why
it's
set
up
this
way
is
that
technically
technically
you
can
have
multiple
tracer
providers,
but
in
practice
you
probably
in
practice
you
can
only
have
one
global
tracer
provider
and
in
probably
99
of
apps
you
will
only
have
one
tracer
provider.
C
If
you
want
multiple
tracer
providers,
you
have
to
manage
all
of
the
non-global
ones.
Kind
of
yourself,
they're
kind
of
like
an
off
the
books.
C
You
are
in
some
very
interesting
use
case
and
know
what
you're
doing,
but
it
leads
like
this
whole
whole
problem
where
you
have
to
like
piggyback
the
resource
on
all
of
your
bits
of
telemetry,
and
this
issue
back
here,
I
think,
was
just
saying:
why
don't
we
just
change
the
processor
and
the
interface
or
change
the
processor
and
exporter
interfaces
so
that
they
just
get
the
re
resource
and
the
reason
why
this
was
not
done
is
because
in
that
convoluted
system
I
just
described,
which
I'm
sure
I
did
a
terrible
job
at.
C
You
could
technically
share
the
same
exporter
between
two
tracer
providers
that
have
different
resources.
If
that
makes
sense,
so
I
don't
know,
I
don't
know
what
to
say
about
this
other
than
like.
I
don't
either
a
quick
read
of
that.
E
C
Stuff
about
your
your
docker
environment,
et
cetera,
et
cetera,
like
all
that
stuff
kind
of
takes
some
time
and
the
cloud
provider
stuff,
especially
often
you're
kind
of,
like
that's
done-
by
making
a
request
to
an
internal
endpoint,
and
you
kind
of
have
to
wait
for
that
to
respond
or
time
out.
C
I'm
reminded,
I
think
I
I
just
wrote
her
some
documentation
around
this,
because
people
kept
stumbling
upon
it
and
for
a
long
time
I
was
kind
of
like
raging
against
like
why
do
we
allow
multiple
tracer
providers
and
that's
kind
of
the
enemy
here
I
kind
of
softened
on
that
a
little
bit,
because
I
think
I
don't
think
the
multiple
tracer
provider
use
case
is
super
useful,
but
I
do
think
being
able
to
have
different
resources
in
your
within
a
process
under
some
other
mechanism
might
make
sense,
but
I
feel
like
I
feel
like
this
is
a
can
of
worms
and
we
should
probably
move
on
before
we
spend
the
whole
meeting
we're
talking
about
it.
C
C
So
these
are
the
questions
he
wants
to
answer:
how
to
represent
http
retries
http,
redirects,
dns
queries,
tls
handshakes.
C
C
And
this
appears
to
be
a
very
active
issue,
all
right
that
was
suspecting
any.
A
C
So
on
that
note,
I
think
there
is
a
lot
going
on
in
our
repo,
so.
C
I
know
there's
this
pull
request
from
andrew
with
action
view
instrumentation.
D
D
D
I
think
I
think
what
francis
wanted
to
discuss
about
it
was
that
I
had
used
some
context,
setting
methods
that
actually
shouldn't
be
used,
and
instead,
the
ones
that
I
should
have
been
using
were
marked
as
api
private.
So
I
think
I
think
that
is
probably
the
most
salient
point
of
discussion
that
comment
right.
There
actually
yeah,
but
I
actually
don't
know
much
more
about
it
beyond
that.
Maybe
if
he's
able
to
join
later,
he
will
have
more
things
to
share
about
it.
E
As
as,
actually
actually
sort
of
this
first
use
of
the
within
open,
telemetry,
ruby,
first
use
of
the
active
support
notification
subsystem
or
are
you?
Are
you
picturing,
maybe
a
a
generic
common
library
for
doing
the
active
support
notification
part
and
then
any
and
any
of
the
name
spaced
things
you
would
subscribe
to
could
could.
D
Reuse
that
thing
that
was
my
thought
yeah.
I
had
initially
implemented
it
entirely
within
the
action
view,
gem
that
I
started
writing
for
it,
and
then
I
actually
moved
the
the
the
special
notification
queue
and
spam
subscriber
out
to
the
rails.
Instrumentation.
E
D
I
missed
that
in
reviewing
it
I
see,
but
yeah,
so
anything
else
could
could
use
that
if
they
wanted
to.
I
think
it's
worth
mentioning
and
I
think
I
said
in
the
pr
that,
like
you,
do
lose
data
this
way.
I
know
we've
talked
about
it
in
the
past.
You
can't
get
as
as
rich
of
instrumentation
as
you
could
get
by
patching
the
classes
and
things,
but
you
know
for
for
things
that
we
want
to
support
quickly
or
for
those
who
want
it.
It
is
a
very
simple
way
of
doing
it.
E
It's
in
our
experience
at
honeycomb.
It
was
a
cheap
way
to
get
shallow
insight
into
activities
happening
within
a
rails
app.
So.
D
Yeah,
I
think
my
thought
was
that
it
it
would
let
us
continue
to
sort
of
light
up
rails
as
a
framework
to
make
it
more
visible
and
then,
as
we
go
through
it,
we
can
amend
or
replace
instrumentation,
as
we
have
time
to
actually
make
better
stuff.
Like
the
action
view,
stuff
could
could
be
done
differently,
you
could
patch
them
the
various
methods
on
on
rendering
you
might
be
able
to
get
more
interesting
information
that
way.
But
you
know
that
all
takes
a
lot
of
time
and
this
was
sort
of
a
quick
win.
C
Yeah,
so
I
see
what's
going
on
here,
it's
kind
of
like
we
have
like
this
with
current
helper,
which
takes
a
block,
but
it's
no.
It's
of
no
use
to
you
when,
like
the
the
code
is
not
co-located,
which
is
kind
of
what's
going
on
in
the
start
and
finish.
D
I
think
the
way
other
people
do
this,
if
I
remember
correctly,
datadog's
active
support
system
actually
patches
the
rails
instrumenter
to
wrap
the
entire
thing,
but
I
didn't
really
feel
like
doing
that,
since
that
would
move
us
into
patching
and
we're
able
to
kind
of
avoid
that
here,
but
that
could
be
another
method
if,
for
some
reason
we
can't
if
this
doesn't
prove
workable
in
practice,
we
there
are
other
ways
that
are
slightly
more
invasive,
that
we
could
do
this.
C
Yeah-
and
there
are
these
attach
and
detach
methods
on
contacts.
I
think
that
francis
is
brought
up
here
back
in
the
day.
We
believe
that
we,
we
definitely
discussed
this,
and
we
discussed
that
they
are
somewhat
dangerous
methods
in
that
you
know,
every
attach
needs
a
corresponding
detach
and
that
detached
must
be
reachable,
which
is
like
a
pretty
big
there's
ways
that
can
go
wrong.
If
you
aren't
super
super
careful,
and
even
if
you
are
super
careful,
I
think
there
are
ways
that
that
can
go
wrong.
C
So
I
think
we
we
decided
to
just
go
with
the
kind
of
the
the
with
block
closure
type
system
or
like
yeah,
the
with
context
and
other
kind
of
closure-based
methods,
because
we
could
handle
we
always
throw
on
a
rescue
and
make
sure
that
we
clean
stuff
up
yeah
and
it
kind
of
encourage
folks
in
that
direction.
C
D
Saw
the
I
saw
the
warnings
in
the
method
actually
that,
if
you
don't
line
up
the
calls
it'll,
warn
you
and
say
you're
doing
it
wrong,
which
is.
G
D
And
I
actually
managed
to
trigger
those
even
without
calling
attach
and
detach
directly.
It
took
a
lot
of
trial
and
error
for
me
to
figure
out
like
precisely
when
and
how
that
was
working,
which
really,
I
think
just
highlights
that
I
don't
understand
the
context
api
as
well.
As
I
thought
I
did,
but
I
agree
it's
a
dangerous.
It
can
be.
Very
you
know,
I
mean
dangerous.
I
guess
is
a
word
doing
a
lot
of
work
in
that
sentence,
but
it
you
could
easily
mess
it
up
if
you're,
not
careful.
C
Cool
yeah,
I
wrote
a
lot
of
that
code
back
when
this
was
originally
implemented,
like
other
languages
where,
like
java
and
other
ecosystems,
were
using
like
grpc's
context
like
the
context
object
from
grpc
itself,
it
didn't
we.
We
did
not
want
to
take
a
grpc
dependency,
just
to
use
that.
So
I
kind
of
read
through
some
of
those
implementations
and
got
some
ideas.
C
C
So
we
can
expose
those
I
feel
like
they
should
be
heavily
documented,
that,
like
you,
can
definitely
mess
things
up
when
you
are
using
these
so
be
aware,
yeah.
D
C
All
right
so
yeah,
I
think
everybody
check
this
out
and
provide
some
feedback
and
if
you
use
it
and
it
works,
let
us.
C
B
G
Utility
pr
can
we
discuss
that
it's
it's
carrying
on
from
last
week,
I
couldn't
come
last
week.
Oh
okay,
great!
Yes,
this
is
your
pr.
Seven
six.
B
G
There
we
go
that
one,
so
I
think
there
was
some
discussion
a
couple
weeks
ago,
which
I
wasn't
here
for
as
well
and
I
sort
of
said
I'd
come
back.
I'd
come
here
to
sort
of
see.
What's
you
know
what
I
could
gather
just
understand
where
to
take
this
really
good.
If
I
gave
an
overview
of
what's
covered
in
this
change,
sure
yeah
give
us
a
summary
yeah.
G
So
the
general
idea
is
that
we
have
several
different
implementations
of
http
clients,
http
clients
and
they
all
generally
need
to
instrument
or
add
the
same
attributes
into
places
and
currently
they're
happening
consistently.
G
Some
clients
are
adding
some
attributes,
others
are
adding
others,
but
for
the
most
part
they
all
have
access
to
the
same
data
they're
just
not
using
in
the
same
way.
So
pretty
much
everything
can
construct
a
uri
that
they
can
then
add
into
an
attribute.
So
one
of
the
things
this
is
trying
to
do
is
basically
come
up
with
a
utility
that
you
could
effectively
just
apply
in
every
http
client
instrumentation
that
someone
wants
to
build.
G
C
Yeah
so
let's
start
a
question
so
yeah
it
seems
like
you,
are
able
to
kind
of
glom
on
all
of
the
attributes
that
that
that
you
can
to
this
utility,
and
it
will
will
it
pick
the
ones
that
it
actually
ends
up
adding
in
the
end,
because
I
know
in
the
specification
there
is
kind
of
like
this.
What
me
the
whole
thing:
yeah,
okay,.
E
This
does
seem
promising
to
centralize
how
we
describe
http
so
that
when
that
sp
tap
or
whatever
comes
along
and
says
what
should
we
do
about
http,
we
have
one
place
to
fix.
It.
G
G
I
think
some
of
the
comments
that
came
out
of
this,
I
think
from
when
it
was
discussed
a
couple
weeks
ago,
was
that
maybe
it
doesn't
belong
in
the
common
gym,
which
I
agree
with.
It
probably
belongs
closest
to
instrumentation
even
helpers.
I
know
there's
also
a
base
instrumentation,
I'm
not
sure
if
it
could
go
there,
but
maybe
I'll
look
at
creating
a
gem
for
that.
A
I
think
one
of
the
things
that
came
out
of
that
is
like,
and
I
think
it's
still
a
bit
of
an
open
question
is
like
what
gem
it
goes
into
and
what
the
name
of
it
is.
I
think
that's
just
a
matter
of
us
just
settling
on
where
to
put
it,
which
I
don't
think
we
should
be
delegating
to
you
and
the
other
part
is
wherever
it
lands.
A
It
should
have
some
sort
of
mix-in
helper
so
that
any
of
these
http
instrumentation
libraries
that
are
using
it,
which
ideally
will
be
all
of
them.
They
mix
in
some
sort
of
config
options.
So,
instead
of
having
every
single
http
installation
library
having
to
re-implement
the
same
configurative
options,
there's
just
part
of
this
helper
jam
just
like
conformity
gem,
would
have
like
a
mix
in
so
they
all
just
get
the
default
config
options.
So
that
way,
you're
still
able
to
individually
say
like
net
http,
whatever
option
off
and
then
something
else
on
right.
G
F
All
right,
hey,
christopher.
I
had
reviewed
this
sorry
for
joining
late.
Everyone,
I'm
not
sorry,
I
don't
care
yeah.
I
thought
this
was
great.
I
think
the
the
actual
work
here
is
like
totally
fine
to
merge
with
the,
except
that
we
want
to
like
do
some
restructuring
of
where
it
lives
and
how
it
gets
included
in
the
it's.
You
know
various
http
instrumentations
I
had
said.
I
would
do
that
last
week
and
I
didn't
so.
I
think
that's
the
hold
up
here.
F
As
I
had
said,
I
would
put
together
a
mix
in
or
something
and
just
never
and
then
life
happened.
So,
but
yes-
and
you
know,
I
think,
all
the
defaults
you
chose
with
off
by
default
on
the
query.
Params
is
the
right,
the
right
posture.
F
You
know,
I
think,
there's
open-ended
stuff
around
like
do
we
want
to
have
hooks.
Do
we
want
to
have
you
know,
exposed
request,
headers,
do
we
whatever
and
that's
you
know
like
tomorrow's?
We
can
worry
about
that
down
the
line.
I
don't
think
it's
blocking,
but
yeah.
I
think
if
the
goal
here
is,
let's
get
this
in
so
you
can
use
it.
I
think
I
am
the
blocker
here,
not
anything
in
this
pr.
As
far
as
I'm
aware,
maybe
someone
else
can.
G
Weigh
in
so
is
this
a
then
an
assumption
of
that
I
could
just
rebase
whatever
you're
going
to
do
on
top
of
this.
On
top
of
your
work,
to
have
it
ready.
F
Yeah,
I
think,
let's
agree
on:
let's
try
to
get
some
consensus
here
on
where
this,
what
gem
this
should
live
in
and
then
I
will
try
to
push
up
a
mix
in
which
you
can
then
rebase
on
and
does
anyone
else
have
feedback?
Does
that
feel
like
an
approach?
People
are
happy
with.
E
F
E
It's
like
a
base
http
or
an
http
mix-in,
so
it
doesn't
have
to
be
like
it
doesn't
have
to
be.
F
D
Gotcha,
I
feel
like
you,
could
create
like
a
base,
http
instrumentation
class-
that
does
some
of
these
things
and
we
mix
it
in
or
inherit
it
from
it,
or
something
like
that.
I
also
kind
of
personally
like
the
idea
of
a
junk
drawer
sort
of
instrumentation
helper
that
might
have
other
mix-ins
like
this.
I
I
don't
know
I
I
mean
I
needed
to
demonstrate.
C
E
There's
a
certain
value,
I'd
say
in
having
one
of
those,
even
if
it's
not
precise,
about
what
help
it's
providing
so
that
we
don't
exacerbate
the
release,
cracking
of
the
huge
amount
of
gems
that
have
to
get
coordinated.
D
D
F
Yeah,
that's
fine.
I
think
there's
going
to
be
in
the
future
helpers
around
quantization
helpers
around,
maybe
some
database.
You
know
standardization
yeah
things
like
that.
So
and
it's
probably
we
you
know
unknown
unknown.
So
I'm
totally
fine.
If
we
just
want
to
say
instrumentation
helpers
or
we
can
worry
about
the
semantics.
E
D
I
mean
in
all
seriousness
I
I
from
what
I
remember
the
conversation
it
was
just.
He
didn't
want
an
instrumentation
based,
because
that
was
a
separate
sort
of
concern
than
what
we
were
talking
about
here.
I
don't
think
he
actually
had
a
problem
that
I
can
recall
with
instrumentation
helpers
or
junk
drawer
or
whatever
we
choose
to
call
it.
I
think
I'm
fine
with
helpers,
I
think
that's
a
great
name.
We
could
do
that
and
start
throwing
some
of
our
stuff
in
the
the
helpers.
A
Yeah,
I
was
gonna
say
that
or
open
telemetry
like
http
card
instrumentation,
http
helpers
like
it,
we
can
scope
it
down.
I
think
the
outcome
should
be
someone
says
like
yes,
I'm
gonna
do
this
and
then
maybe
the
like
finer
bike
shed
can
happen
on
the
pr
if
it's
needed
right
like
on
the
name,
I
think
that's
reasonable,
who
who
is
claiming
this
just.
F
Yeah,
it's
me
I
I
have
to
do
it.
I
haven't
done
anything
in
a
while
yeah,
my
zipkin
pr
was
not
short
enough
yeah.
I
just
sorry.
I
have
an
employer,
that's
not
great.
F
G
G
Yeah,
no
I've
I've
got
hacks
in
place
and
I'd
like
to
remove
the
hacks
so
totally.
F
Understood
and
we
you
know,
I
think
I
speak
for
everyone
when
we
want
to
impa.
You
know
we
want
to
you're
the
you
know.
We
want
to
make
sure
end.
Users
here
can
yeah
be
prioritized
so.
D
I'm
excited
for
the
the
helpers
gem
actually
because
I
think
there's
a
couple
of
other
things.
We
can
and
should
extract
pretty
quickly,
like
all
the
database
stuff
is
getting
a
little
unwieldy
and
and
with
robert
and
I
being
in
the
queuing
land
recently
like
I,
there
was
like
back
and
forth
of
us
synchronizing
our
options
across
different
pr's
when
like
in
reality.
It
would
be
great
if
that
was
just
in
one
spot.
You
know.
G
F
D
Legitimately,
if
you,
if
you
run
into
any
scheduling
problems,
I
can
probably
try
to
help
pick
it
up
if
you
just
if
you
feel
like
you
can't
get
to
it
just
let
me
know.
A
G
F
In
the
instrumentation
folder,
that
probably
will
need
it
I'll
try
and
do
this
yeah
sounds
about
right
yeah,
I
would
say
I
don't
think
we're
a
lot.
You
know
like
from
a
correctness
perspective
like,
I
think,
I'm
totally
fine.
If
you
have
specific
gems
that
you
feel
like
you
need
to
ship
for
your
and
then
we
can
worry
about
the
others
later,
but
yeah.
Obviously,
if
we
get
them
all
done
in
one
thing:
yeah,
that's
fine!
I
think
you
know
once
you
do
it
once
you
can
do
it
to
the
others
pretty
quickly
for.
A
C
Well,
it
sounds
like
we
have
a
way
forward
on
this,
so
that's
a
great
discussion
and
thanks
for
showing
up
chris
to
to
have
this
discussion,
so
we
can
pull
this
thing
or
over.
The
finish
line
seems
like
my
problem
yeah.
It
seems
like
there's
this
whole
whole
kind
of
group
yeah,
there's
this
whole
area
of
code
that
we
need
a
place
for
that
will
make
everybody's
lives
easier
going
forward.
Deciding
where
that
is
is
usually
the
bigger
problem.
C
Should
we
move
on
to
looking
at
the
ga
1.0
milestone
and
try
to
triage?
What's
there
and
kind
of
talk
about
what
issues
have.
C
A
A
A
I
kind
of
put
in
a
sorry
hijack,
I
kind
of
put
in
a
hanky
little
change
after
I
got
some
approvals
that
one.
So
if
you
just
look
at
the
code
itself,
it's
quite
small-
you
won't
see
it
in
there
because
I've
changed
it
since
then.
So,
if
you
know
the
files
changed,
it's
pretty
small,
so
it
was
approved
and
working,
except
for
jruby
jruby,
doesn't
have
the
same
encoding
issues
as
mri.
A
D
E
A
Okay,
I'm
hoping
that
maybe
because
I
think
christopher
has
an
open
issue
with
undefined
conversion
error
yeah.
I
I
ran
into
that
with
otlp.
Just
recently,
the
structure
of
the
otp
exporter
was
a
little
bit
more
friendly
because
it's
not
doing
the
batching,
so
I
could
put
a
little
rescue
in
there
and
just
return
back
an
encoding
error
as
the
attribute
value
to
the
key
I
looked
at.
I
was
I
actually
looked
at
that
issue
and
obviously
with
the
batching.
It's
not
as
easy
as
saving
the
span,
so
yeah.
G
Yeah,
the
problem
isn't
happening
for
us
anymore
because
we
actually
changed
the
kafka
topic
that
service
was
reading
from,
and
so
those
messages
were
no
longer
appearing.
However,
it
didn't
seem
like
there
was
really
a
way
to
find
out
what
messages
were
causing
the
problem.
So
it
was
hard
to
like
you
know,
go
back
and
look
at
stuff,
so.
G
A
way
to
I
don't
know
sorry
failing
grace
handed
me
gracefully.
That
would
be
nice,
but
I
I
won't
actually
benefit
from
it,
because
there's
not
a
problem
anymore.
So.
C
D
A
So
I
don't
think,
there's
an
issue
for
it.
I
think
I'm
gonna
claim
it.
It's
related
to
andrew's
pair
with
the
action
view
around
the
api
for
context.
So
I
don't
think
he
made
an
issue
for
that,
but
it
was
mentioned
on
the
comment
already
so
like.
We
need
to
probably
update
it
a
little
bit,
because
I
think
that
our
implementation
doesn't
match
the
specs.
So
I'm
going
to
be
correcting
that.
D
More
than
happy
to
let
you
do
it,
I
was
going
to
do
it
because
it
sounded
like
it
needed
to
be
done,
but
you,
if
you
actually
really
understand
it
better,
then
I
am
more
than
happy
to
let
you
do
it
because
I
it
was
going
to
be
a
bit
of
a
learning
adventure
for
me
along
the
way.
So
I
don't
mean.
A
To
hijack
it,
I
wouldn't
say
that
I
understand
it
super
well.
I
just
yeah
francis
knocked
up
the
last
two,
so
I
thought
I
would
take
up
the
mantle.
D
Yeah
well
whatever
you
prefer,
I'm
happy
too.
If
you
don't
want
to
otherwise
I'll
do.
D
C
Cool
I'm
happy
to
answer
any
questions
about
the
contact
system.
If
I
can
get
any
help.
C
A
Feel
like
they
used
to
go
the
other
way,
I
think
you're
right.
No.
This
morning
I
was
looking
at
it
and
I
got
really
confused
because
everything's
flipped,
and
also
because
france
has
fixed
a
few
this
morning
they
disappeared.
So
I
was
actually
pretty
confused
myself,
the
the
one
at
the
bottom
there,
just
as
an
aside,
is
a
pretty
interesting
one.
If
anybody's
wants
to
do
that,
that
one
looks
actually
kind
of
fun.
A
I
I
was
thinking
of
maybe
doing
it,
but
I'm
willing
to
offer
that
one
up
it
just
looks
like
it
could
be
a
little
bit
different
of
a
task.
C
C
So
all
right,
so
it
looks
like
I
guess,
we'll
just
go
through
these
and
say
what
we
know
about
them.
So
this
one
is
interesting
and
help
is
wanted.
So
if
you
are
interested
in
trying
to
generate
these
from
yaml,
that's
probably
a
fun
task.
I
think
the
follow-up
task
is
then
to
use
these
generated.
Constants.
E
In
theory,
maybe
they
would
end
up
in
the
same
spot.
I
I
appreciate
how
the
all
the
examples
for
generating
these
things
are
about
http
attributes,
so
it
probably
affects
our
centralizing
of
http
helpers
too.
E
Like
if
you
click
on
the
code
generator
there,
it
takes
you
to
a
section
in
the
build
tools
tree
on
semantic
conventions,
about
http
attributes.
C
Yeah,
it
does
seem
interesting.
I
feel
like
the
one
thing
that
just
like
makes
me
a
little
uneasy
about.
This
is
like
you're,
going
to
regenerate
these
someday
and
go
to
the
code
base
and
find
that,
like
there
are
some
undefined
constants
and
be
scratching
your
head
about
it,
but
maybe
we'll
figure
that
out.
Maybe
I
know
there
is
this
idea
of
having
a
telemetry
schema
for
different
versions,
so
maybe
we'll
be
able
to
magically
upgrade
stuff
with
some
more.
A
Code,
have
we
said
enough
about
that
one
I
think
so
another
one
I
want
to
just
sneak
into
while
I'm
thinking
about
it.
Is
that
we'll
try
to
do
an
rc2
this
week.
I
think
just
a
few
spec
changes
and
a
bunch
of
different
fixes,
even
like
I
want
to
get
that
encoding
fixed
out.
That's
part
of
the
sdk,
so
I'd
like
to
get
that
out
this
week,
because
someone's
bugged
snag
might
be
making
a
lot
of
noise
right
now.
C
A
That's
a
good
question.
I
think,
there's
already
a
substantial
amount
of
stuff
that
has
gone
in
recently
that
it
would
probably
be
good
to
get
that
out.
I
would
like
to
try
to
get
the
the
context
thing
in
just
because
I
think
I
should
do
that
before
anything
else
get
that
change
in
so
that
updates
can
be
done
as
necessary
and
unblock
andrew
other
than
that.
I
don't
think
any
of
these
particular
issues
should
be
blocking.
C
I
remember
francis
talked
about
this
one
a
little
bit
ago.
I
think
yeah.
I
think
we
are
auto
tech,
auto
detecting
if
a
fork
has
happened
by
saving
the
pit
and
checking
the
pit.
I
figured
exactly
where
this
is
happening
and
how
often
this
is
happening,
but
apparently
it's
a
little
wasteful.
C
A
So
I'll
either
fill
it
in
or
get
friends
to
fill
it
in,
or
one
of
us
will
just
fix
it.
Basically,
on
our
kind
of
internal
bespoke
instrumentation.
I
don't
know
if
you've
seen
his
name
pop
around
he's
pretty
active
in
the
ruby
community
by
root
this
is
github
handle.
He
ran
some
profiles
on
a
few
different
applications
and
he
found
that
a
non-zero
amount
of
time
was
being
spent
calling
to
processpid.
A
C
Cool,
so
I
guess,
if
this
interests
you
and
you
see,
a
description
go
in
feel
free
to
pick
it.
F
D
Not
at
all,
it
seems
like
it's,
I
would
even
say,
maybe
a
good
first.
It
seems
like
pretty
easy
actually
to
to
to
implement.
I
mean
I
say
that
knowing
that
that's
like
famous
last
words,
but
it
does
feel
like
it
could
be
a
relatively
simple
change
yeah.
I
agree.
D
Yeah
so
now
they
start
sorting.
Strangely
again,
I
don't
know
what's
happening,
but
you
know
I
actually
looked
through
our
commit
history
and
I
have
no
idea
what
might
have
changed
sounds
like
something
something:
databases.
D
C
I
just
kind
of
nebulously
felt
that
there
could
be
some
improvements
to
the
configurator
being
the
person
who
is
responsible
for
introducing
that
in
the
first
place
and
yeah.
But
I
didn't
have
like
a
specific
plan
in
mind.
So
but
yeah
like
I
feel
like
I
feel
like
robert,
had
had
some
ideas.
C
I
don't
know
if
you
have
some
ideas
if
we
need
to
have
a
melding
of
the
minds,
because
I
think
it
does
make
sense
that
if,
if
this
is
hard
to
use
or
if
there's
something
that
we
can
do
before,
ga
that
we
we
do
address
this-
that
we're
happy
moving
forward.
D
C
D
A
Oh,
this
has
to
be
called
before
that
because
it
actually
sets
something
up,
and
it
was
just
a
lot
of
implicit
stuff
happening,
but
the
more
I
worked
with
it
like
the
api
that
it
exposes,
I
think,
is
fairly
reasonable.
Like
it's
not
there's,
not
a
lot
of
surface
area,
it's
like
the
ability
to
quickly
add
a
service
name
or
a
service
version,
and
you
can
say,
as
fan
processor
things
like
that,
like
I
think
it
depends
on
how
we
want
to
approach
this.
A
Is
it
from
the
outside
utility
of
it
or
if
we
want
to
make
the
maintenance
of
it
potentially
easier,
and
even
that
comes
with,
like
a
big
caveat
that,
like
I
don't
know
if
it's
necessarily
hard,
because
that
realistically
like
how
much
time
has
any
of
us
had
to
spend
recently
in
there
or
making
changes
like?
Is
it
hard
to
work
on?
Is
it
hard
to
reason
about
it?
Doesn't.
A
D
I
haven't
found
it
that
hard
to
work
on
I've
poked
around
at
it.
I
think,
from
a
ga
perspective,
we
would
be
more
concerned
about
the
user
facing
side
of
it,
since
that
would
be
harder
to
change
we,
you
know
we
could
change
the
implementation
of
it
with
as
long
as
we
keep
the
same
api
later
on
pretty
easily.
While
I
would
hope
anyways.
A
I
guess
the
question
is
like
for
a
new
user.
Can
we
make
this
easier,
or
is
it
just
a
matter
of
beefing
up
docs
and
providing
various
examples
to
go
along
with
how
to
configure
an
application?
A
Like
one
of
the
issues
I
saw
on
the
board
it's
like,
should
we
be
providing
recommendations
of
where
you
should
even
do
this
right
like
I
saw
some
one
of
the
issues
and
they
have
their
setup
somewhere
a
little
bit
odd.
From
my
perspective
like
if
you
have
a
typical
rails
application,
I
expect
this
to
probably
get
called
an
initializer,
probably
or
in
real
time,
not
in
some
other
places.
So,
like
I'm
wondering
if
a
lot
of
it
isn't
really
just
documentation.
D
I
think
so
I
think
we
could
write
the
documentation
and
maybe
that
could
inform
what
changes
might
need
to
be
made
like
there
are
a
few
things
about
it
like
the
way
we
have
to
sort
of
always
add
a
batch
ban,
processor
and
random
things
like
feel
a
little
odd
to
me,
but
also
not
horribly
odd,
but
I
think
maybe
writing
the
docs
for
it
and
explaining
it
to
people
would
then
tell
us
what
we
really
don't
like
because,
like
in
all
of
my
apps,
I've
set
it
up
and
I
don't
touch
it
anymore,
and
so
it's
not
fresh
but
like
writing
up
the.
E
I
was
talking
with
a
different
group
this
morning
about
a
I
don't
remember,
which
language,
but
in
open
telemetry.
One
of
the
open,
telemetry
implementations
has,
for
example,
a
the
equivalent
of
a
gem
for
a
local
collector,
and
if
you
grab
that
library
and
depend
on
it
and
say
it's
a
one
line
config
to
get
the
standard
pipeline
of
a
batch
band
processor
that
sends
to
otlp
on
a
local
host
on
the
default
port
for
a
collector.
E
That
sort
of
convenient
stuff
can
make
it
easy
for
people
to
pick
up
hotel
and
not
have
like
to
to
go
to
matt
your
example.
There
of
like
a
c
enable
b3
that
does
all
the
things
like
all
you
want
to
know
is
that
I'm
using
b3
headers-
and
I
don't
want
to
have
to
know
that
open
telemetry
has
a
thing
called
a
text
map
propagator.
I
just
want
to
use
headers.
D
Think
we're
actually
pretty
close
to
that
ideal.
Maybe
yeah,
maybe
I
don't
think
we're
completely
there,
but
I
think
we
could.
Maybe
maybe
that's
something
to
tweak,
is
what
defaults
do
we
pull
in
when
you
load
it?
I
don't
know.
E
I
super
like
the
cr.
I
super,
like
the
the
like
the
otlp
exporter,
defaulting
to
assuming
that
there's
something
listening
on
localhost
like
if
you,
if
you
don't
want
to
send
it
to
a
collector
running
as
an
agent,
then
then
you
feed
it
config
to
tell
it.
I
think
it.
A
Yeah,
it
that's
historical,
I
think
it
changed.
It
originally
was
five,
five,
six
zero
or
whatever
yeah,
and
then
the
spec
change-
and
I
don't-
I
guess
we
haven't
caught
up
but
yeah
by
default,
like
the
the
configurator.
Does
a
lot
of
that
stuff,
like
it
it'll
try
to
set
up
your
default
propagation
and
your
exporter
and
all
that
stuff
which,
like
I
think
I
understand.
D
E
D
Oh,
we
do
default
to
the
batch
spam
processor.
Oh
that's
good!.
E
But
also,
you
know,
we
can
document
the
fiddly
and
then
we
can
add
convenient.
We
can
always
add
convenience
methods,
so
I
think
we
could
go
1.0
without
taking
on
making
things
too
easy
so
like
like
hard
matches
the
spec
and
that's
stable,
and
then,
if
we
choose
to
add
convenience
methods,
it's
due
later
cool.
E
A
I
think
definitely
like
what
andrew
was
saying
before
is
that
documentation
of
it
should
be
like
the
improved
documentation
and,
like
examples
should
be
probably
part
of
this
issue,
and
then,
if
that
surfaces,
any
like
convenience
or
helpers
or
anything
like
that,
that
should
come
as
a
result
of
it.
That
would
be
really
good,
but
I
think
one
of
the
biggest
things
right
now
is
just
better
documentation
because
a
lot
of
times,
I
think
we
don't
get
a
ton
of
support
issues,
but
a
lot
of
times.
A
It's
people
just
be
doing
the
initial
configuration,
and
sometimes
it's
like
the
examples,
are
on
a
date
or
we
removed
the
exporter,
keyword
from
the
matchman
processor
and
that
caught
a
few
people.
So.
E
Also
for
documentation
is
there.
I
know
that
we
generate
like
the
ardoc
stuff
out
of
each
gem
and
those
all
get
aggregated
to
a
single
site,
but
the
like
landing
page
for
that
doc
site
is
just
a
list
of
the
gems
we
that
could
be
better.
How.
A
I'm
bad
for
writing
dots,
so
I'm
probably
not.
I
have
no
opinion.
I
will
refer
to
people
who
care
strongly.
E
I'd
be
curious
about
how
to
make
that
landing
page,
not
just
a
list
of
the
gems
that
you
have
to
then
go
drill
into,
and
then
the
gems
sort
of
document
how
to
use
them,
but
not
necessarily
in
concert
with
the
other
stuff
like
having
something
that
that
is
like
a
a
quick
on-board.
How
do
you
pick
this
thing
up,
which
would
be
where
we
would
document
things
like
this
or
maybe
not
the
nuance
of
switching
out
your
propagation
headers,
but
like?
How
do
you?
D
No,
I
think,
you're
right,
I
think
another
page
you're
talking
about.
I
don't
actually
know
how
that's
generated
I
think
like.
Even
though
we
have
a
lot
of
documentation,
I
think
it
could
be
more
discoverable
like
it
feels
like
it.
It's
it's
there.
You
just
kind
of
have
to
know
where
to
go
and
where
to
look,
and
that's
that's.
D
The
battle
I
do
have
to
drop
off,
though,
because
I
gotta
run
to
another
meeting
but
yeah.
It's.