►
From YouTube: OpenTracing Meeting GMT 2017-12-01
Description
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
So
if
you're
recording
Yuri
I'll,
kick
it
off
yep
great
all
right,
everyone
welcome
to
our
monthly
OTS
C
call
I'll,
be
your
MC
today,
we're
gonna
go
around
the
room
and
try
to
do
just
a
quick
intro.
So
if
you
can
say
your
name
where
you
work
in
your
relation
to
open
tracing
in
a
single
line,
that'd
be
great
and
since
I
don't
believe,
there's
a
stable
participants
list,
necessarily
I'll
just
be
calling
people
off.
E
F
G
A
M
M
M
A
A
But
let's
kick
it
off
with
what
I
think
is
the
most
important
thing,
which
is
the
the
31
release
of
the
Java
API
I
feel
like
we're
basically
ready
to
put
out
a
second
and
hopefully
final
release
candidate
for
the
new
API
Thanksgiving
kind
of
kind
of
swamped
feedback.
I
feel.
My
really
my
only
concern
with
getting
this
thing
out
right
now
would
be
testing
the
backwards
compatibility
proposal
and
making
sure
that
that's
actually
going
to
work.
It's
not
going
to
be
perfect,
no
touch
backwards,
compatibility,
but
a
number
of
believe.
A
It's
really
important
to
have
a
form
of
backwards
compatibility
where
you
just
need
to
change
the
import
paths
on
your
various
libraries
and
application
code,
rather
than
actually
change
all
of
your
instrumentation
and
be
able
to
sort
of
gradually
change
your
instrumentation
over
from
one
API
style
to
the
other
a
little
concerned.
If
we
don't
offer
something
like
that,
then
people
will
you
really
stuck
on
the
old
API
and
tracers
will
be
stuck
having
to
support
sort
of
a
version
skew
across
api's
and
I
feel,
like
that's
just
too
too
much
to
ask
of
people.
A
Considering
that
we're
a
standard,
we
should
be
doing
the
effort
to
really
you
know,
try
to
make
that
easy
for
people.
So
my
first
question
is:
does
anyone
have
any
feedback
or
concerns
with
how
that
is
currently
being
implemented?
And
then
my
next
question
after
that
will
be?
What
do
we
need
to
do
to
actually
test
this
in
the
real
world
before
declaring
the
release?
Candidates
final?
So
let's
start
with
the
first
question:
does
anyone
have
any
concerns
about
this
approach
or
feel
like
it's
not
going
to
work?
I.
D
E
Yeah,
it
will
be
an
artifact,
so
it
will
be
part
of
the
release.
So
basically,
we
have
like
several
artifacts
that
are
like
are
the
base
of
open
tracing,
which
is
like
open
tracing
API
open
tracing,
not
so
open
tracing
these
ideas.
You
know
3-0,
it's
like
just
another
artifact,
so
so
the
idea
was
to
separate
everything
and
we're
trying
to
ring
and
not
mess
up
with
the
with
the
rest
of
the
main
stuff.
So
yeah,
it's
going
to
be
part
of
these.
Are
they
for
stock,
but
it's
going
to
be
a
separate
artifact.
A
So
this
means
the
the
three
people
who
have
to
change
their
code.
Tracers
will
have
to
make
a
modification
so
that
they're
they'll
have
to
issue
an
artifact
that
binds
to
this
new
namespace
and
then
they'll
be
able
to
use
a
shim
to
take
their
new
tracer,
the
one
that
conforms
to
the
new
31
API
and
use
it
through
a
shim
in
this
package
that
produces
a
version
of
the
old
API.
So
the
hope
there
is
that
people
who
are
developing
tracers
won't
need
to
maintain
a
30
and
a
31.
A
They
can
just
retain
maintain
a
31
and
users
when
they
switch
their
imports
over
will
be
able
to
consume
updates
from
that
new
tracer.
But
the
third
piece
is
that
library's,
any
like
library
instrumentation
will
need
to
have
some
version
of
it.
That
also
switches
over
to
this.
Just
so
the
namespaces
line
up
and
we'll
need
to
come
up
with
some
I'm
thinking,
like
some
standard
tag
or
other
way
of
you
know
indicating
that
this
is
the
the
shim
version
of
this
library.
A
So
there'll
be
a
need
as
a
community
for
us
to
go
into
all
of
our
library.
Instrumentations
and
open
tracing
country,
but
elsewhere
and
kind
of
make
a
tag
version
that
that
is
set
up
like
that.
There
shouldn't
be
a
lot
of
work,
but
if
we
don't
do
that
work,
then
people
will
be
kind
of
stuck
in
a
weird
middle
ground.
Can.
K
I
ask
a
quick
question.
Anything
that's
not
quite
clear
to
me
is
what
impact
is
this
going
to
have
on
trace
implementers?
Is
this
compatibility
later
going
to
be
just
completely
transparent,
or
is
this
something
that
each
of
the
trace
implementers
are
also
going
to
need
to
implement
the
interfaces
of?
K
A
Should
be
able
the
hope-
and
this
is
where
I
want
implementers
to
actually
do
this
work
as
a
release
candidate
before
we
declare
its
final,
but
the
hope
is
that
you
should
be
able
to
just
switch
your
tracer
over
to
the
new
API.
So,
however,
you
were
bridging
to
open
tracing
you're
gonna.
Do
the
work
to
bridge
to
the
new
31
API,
and
then
there
is
a
shim
layer
that
will
provide
a
continuation
support,
so
the
mechanisms
for
supporting
the
old
30
API
you
shouldn't
you
shouldn't,
have
to
right.
A
You
should
just
be
able
to
focus
on
31
and
not
have
to
worry
about
that
and
that
shim
layer
will
do
the
reference
counting
and
continuations
for
you
I'm
fairly
certain
that
will
work.
But
it's
not
clear
to
me
for
tracers
that
we're
not
using
reference
counting
or
we're
doing
something
funny
I
mean
I,
don't
mean
funny,
but
I
mean
different
from
that
model.
Whether
there
would
be
some
impedance
mismatch
to
have
that
reference
counting
happen
on
top
of
them.
Does
the
only
thing
I
can
think
of
that.
K
A
A
Just
have
one
version
of
your
tracer:
that's
updating
and
asking
your
users
if
they
want
to
receive
those
updates
to
move
over
if
they
want
to
receive
the
updates,
but
don't
want
to
update
their
code
to
the
new
API
or
they're
in
the
process
of
doing
it.
They
should
be
able
to
use
this
alternate
package.
Okay,.
K
A
So
there
was
some
debate
about
that.
My
feeling
is
that
it's,
it
really
should
be
in
there,
because
this
is
like
a
core
part
of
the
open
tracing
spec
should
be
providing
a
clear
path
to
backwards.
Compatibility
I,
don't
anticipate
we're
going
to
be
doing
I
mean
my
hope
is.
This
is
the
end
of
you
know
any
kind
of
API
change
that
would
affect
instrumentation.
K
A
M
I
feel
like
there's
a
lot
of
Merit
having
documentation,
you
know
front
and
center
as
part
of
the
project.
That
would
explain
anything
regarding
backwards
compatibility.
There
is
some
kind
of
aesthetic
thing
to
me
about
having
literally
as
little
as
possible
in
central
like
core
location,
and
it's
not
necessary
to
put
this
there.
So
by
that
as
little
as
possible.
Like
the
roles
done,
we
would
leave
it
somewhere
else,
but
it's
not
I
mean
I,
don't
think
anyone's
arguing.
It
should
be
part
of
the
same
navin
artifacts
or
something
like
that.
M
That
part
I
think
we're
all
on
the
same
page.
So
this
is
really
just
about
literally
where
the,
where
the
code
was
and
github.
So
it's
maybe
a
little
bit
less
important.
Somebody
codes,
work
standpoint,
but
I
I
think
I
would
slightly
but
argue,
but
not
strenuously
for
having
it
in
a
separate
location.
If
we
wanted
it
to
feel
official
or
whatever
it
could
be
part,
we
should
have
like
open
tracing
or
exactly
that
open
tracing.
Comparing
the
word
repository
for
translation
layers,
and
things
like
that.
M
If
you
wanted
to
feel
like
it's
part
of
this
off
location,
but
I
know
that
when
I
go
to
a
repository
for
something
that's
recording
to
be
simple,
which
is
you
know,
the
idea
wasn't
raised,
saying
it's
just
via
groves
a
sin,
API
and
then
I
just
see
like
you
know,
tens
of
thousands
of
lines
of
code
strewn
about
across
many
directories
a
lot
of
cruft.
It
doesn't
have
like
objects
in
some
way.
M
So
I
wonder
if
there's
a
way
to
to
check
your
box
head
around
like
feeling
as
a
formal
part
of
a
specification
that
were
taking
it
seriously,
but
somehow
keep
it
out
of
the
repository
itself
where
it
might
be
distracting
or
seem
noisy,
yeah
I.
Don't
know
well,
I
bet
for
that
too.
That's
big!
That
would
be
cool
if
we
can
check
both
attractive
well.
A
I
wonder
if
the
middle
ground
is
I,
definitely
don't
think
it
should
be
open.
Tracing
can
trim
that
that
just
sounds
like
this
I.
You
know
it.
This
needs
to
be
official
backwards.
Compatibility
support
from
the
open
tracing
community,
but
I
wonder
if
it
could
just
be
another
repo
and
open
tracing
is
supposed
to
open
tracing
can't
rip.
That
would
give
it
I
think
the
right
amount
of
visibility
for
what
it
is.
Does
that
seem
like
a
reasonable
middle
ground
people.
L
L
Not
sure
because
looks
like
nobody
use
it
because
I
started
to
use
it
and
it's
a
pain,
it's
so
pain
because,
for
example,
I
cannot
shrimp.
Any
tracer
tracer
should
should
have
scope
manager
which
will
be
implemented.
Cific
interface,
yes,
I
cannot
use
any
scope,
manager,
implementation
inside
tracer,
which
will
be
shipped
okay.
A
Well,
maybe
this
is
another
argument
for
being
able
to
move
it,
move
it
into
its
own.
Repo,
then
think
that
would
allow
us
to
have
these
things
decoupled
enough
that
we
can
continue
to
do
work
on
that.
We
need
to.
We
definitely
need
this
thing
vetted
in
reality.
That's
that's.
Definitely
the
missing
piece
here
so
I'm
with
you
on
that
yeah
something
yeah.
E
Julie,
you
were
going
to
say
something:
okay,
yeah,
okay,
so
yeah
I
was
thinking
that
yeah,
probably
putting
this
trim
layer.
You
know,
even
if
it's
in
the
same
open
tracing
repo
or
having
it
separated,
would
allow
us
to
do
more,
like
bug
fixing
like
faster
right,
probably
so.
That
would
be
a
probably
a
good
thing
about
that.
Okay,.
A
A
A
Let's
maybe
consider
that
item
of
topic
settled
unless
someone
else
has
anything
else
to
say
there
and
really
like
the
main
thing
is
for
the
people
who
are
tracing
implementers
on
this
call
just
be
prepared.
You
know
starting
next
week
to
try
to
really
bet
this
thing.
As
soon
as
we
get
a
release
candidate
out
of
the
new
31
API,
we
want
to
start
vetting
all
of
this
stuff
in
reality.
So
let's
make
sure
that
we're
we're
setting
some
time
aside
in
our
schedules
to
do
that
work.
A
Alright,
so
there's
a
couple:
little
bike,
sheds
kind
of
left
around
the
Java
API
around
naming
conventions-
you
know,
should
should
start
active.
You
know,
have
a
boolean,
that's
required,
or
the
optional
etc.
I,
don't
think
I,
don't
think
those
are
very
controversial.
The
one
that
did
seem
to
have
some
real
open
questions
left
was
around
the
binary
carrier
and
I
think
we
should
have
a
bit
of
a
discussion.
There
I
think
it's
there's
agreement
that
there
shouldn't
be
an
extra
binary,
holder,
type
or
some
other
binary
type.
A
There
should
just
be
binary,
but
there
was
some
debate
I
think
from
Yuri.
Maybe
about
do.
We
need
a
binary
carrier
at
all
and
what
shape
that
should
be
if
we
are
going
to
change
it
from
its
current
shape,
which
is
not
useful
for
background.
What
makes
the
current
binary
carrier
awkward?
Is
it
a
byte
buffer
where
you
have
to
know
the
size
in
advance
and
that's
not
very
useful,
so
you
want
to
switch
to
something
if
we're
going
to
keep
it.
E
Yeah
I
think
that's
so
far.
The
effort
is
going
well
well.
I've
been
working
on
that
so
and
I
think
I've
had
beginning
some
people
from
Sergey
and
from
Julie,
so
I
hope
we
can
keep
going
so
the
latest
feedback
prison
from
Sergey
was
to
actually
put
that
support
into
mock
tracer,
so
he
can
actually,
for
example,
trace
himself
like
you
know
not
only
like
playing
around
but
try
it
in
a
more
serious
fashion.
E
So
if,
unless
Julie
has
something
has
to
say,
I
think
I
will
just
post
and
updated
to
requests
later
today
and
use
wait
for
more
feedback
and
I.
Don't
know
everybody
else.
What
my
impression
is
that
we
are
going
like
it
just
iterating
over
each
but
I
hope.
Now
we
are
closer
much
closer
than
before
to
getting
it
actually
don't.
A
L
M
He
was
sorry
yeah
I
was
gonna,
say
that
you
know
they're
not
on
this
call,
but
I've
spoken
with
some
of
the
people,
from
Google
working
on
up
in
census
and
and
on
SEO
as
well,
and
the
you
know,
they're
really
sensitive
to
any
literally
any
performance
impacts.
Even
just
like
a
simple.
You
know:
CPU
turning
performance
impact
on
serialization
and
deserialization,
and
if
they
were
on
this
call,
they
would
certainly
insist
on
having
support
for
it.
A
By
the
way
point
of
processor
zoom
has
a
raised
hand,
function.
I
know
it
can
be
sometimes
a
little
hard
to
jump
in
feel
free
to
jump
in
whenever.
But
if
you
also
raise
do
the
raise
your
hand
but
using
that
tool,
I'll
make
sure
to
call
on
you
I
think
the
other
point
of
process
on
getting
binary
is
whether
that
should
go
into
thirty-one.
A
If
there's
some
debate
about
this,
should
we
delay
in
order
to
get
that
resolved
I
personally,
think
it
absolutely
should
go
into
thirty-one,
because
it's
a
essentially
breaking
change
to
the
instrumentation,
API
and
I
feel
like
thirty-one
should
instance,
where
it's
known
we
should.
We
should
get
it
done
in
this
iteration,
but
if
anyone
has
any
objections
to
that,
please
raise
them.
A
A
A
A
No,
all
right
sounds
good
if
you
do
just
put
them
on
the
agenda
and
we'll
talk
about
it
at
the
end.
Okay,
so
next
up
is
Python,
which
is
the
other
sort
of
big
API.
That's
moving
over
to
this
active
span
process
and
Manu
I
believe
you've
been
holding
that
down.
Would
you
like
to
give
an
update,
yeah.
J
J
It
could
work
for
me
that
may
not
work
for
me
because
actually
I
mean
we
are
only
relating.
We
are
sorry
only
relying
in
tests,
personal
examples
and
stuff
like
that,
so
it
will
be
better
having
more
consensus
about
that.
I,
don't
know
you
Yuri.
If
you
have
any
concern
about
that,
since
you
near
you
have
mean
with
the
Jager,
you
have
a
good
client
I,
don't
client
I,
see.
C
J
About
that,
just
to
give
us
some
more
context
about
tornado
industry,
we
are
supporting
tornado
with
this
kind
of
approach,
but
mostly
we
are
hiding.
The
real
problem
at
is
using
a
stock
context.
It's
okay,
tornado
things,
but
yeah
the
API
is
kind
of
working,
but
it's
not
like
the
turn,
Locker
storage,
so
that
you
really
have
just
a
getter
and
just
a
setter.
So
it's
just
to
give
more
details
about
that,
and
so
one
thing
that
would
be
very
great
is
yes
keeping
the
conversation
on
also
for
Pfizer.
J
I
know
that
Java
is
of
course
the
highest
priority
right
now,
but
if
anyone
is
interesting
to
jump
in,
it
would
be
great
and
about
the
example.
Carlos
I
mean
I
think
that
in
the
meantime,
while
people
may,
if
people
may
have
more
time
in
the
meantime,
we
can
provide
more
examples,
start
trying
this
new
API
and,
at
some
point
I,
will
start
reiterating
of
iterating
over
your
comments.
I
think
it
could
be
the
next
step
for
Python
great.
E
Yeah,
so
for
everybody
for
everybody
who
doesn't
know
about
this
effort,
we
have
an
a
small
repo
with
Python
in
Santos,
so
yeah
I
started
porting
them
to
this
tour
request.
Man
who
has
provided
what
I
was
stuck
in
the
middle
because
of
course
there's
so
much
other
stuff
going
on,
but
the
I
hope
I
can
find
some
cycles
to
to
finish
that
and
from
that
iterate.
So
yeah
I
think
that
yeah
well
yeah
yeah.
We
tried
to
put
some
sense
into
that.
Definitely.
A
B
So
yeah,
basically
we
covered
everything
from
big
one.
We
had
some
iterations
safety.
We
simplify
the
API
in
in
the
last
month
and
basically
some
feedback.
We
got
for
like
the
most
important
piece
now
or
the
most
boring
piece
now
that
we
are
lacking
now
is
in
process
context
propagation.
So
for
that
we
are
basically
waiting
for
the
Python
pull
request
to
get
merge
and
then
replicate
the
same
approach
in
PHP.
B
Once
we
have
the
Python
pull
request,
merge
we
can
in
replicate
that
and
then
open
a
pull
request
and
see
if
it
works
for
everyone,
because
there
are
two
main
pieces
that
we
are
lacking.
Php
one
is
that
in
process
calls
propagation
and
the
other
one
is
the
wolf
nation
and
those
are
very
important
before
any
tracing
system
in
PHP
can
go
into
production.
B
Just
I
would
like
to
mention
something
about
a
ball
reporting,
so
I've
been
exploring
the
possibility
of
using
agents
and
do
bulk
reporting
through
TCP
I.
Don't
know
if
anyone
has
experience
with
fluency
and
for
basically
general
agents,
but
like
that's
what
we're
exploring
now
for
some
tracers
that
don't
have
agents
like
Zipkin,
for
example,
and
seems
like
as
I
said,
this
bug
reporting
is
a
must
in
PHP
production
systems.
So
if
anyone
has
experience
with
agents
fluently
in
particular
or
custom,
written
agents,
I
would
love
to
have
a
chat.
Now.
M
M
A
J
A
Okay,
TBD
I
have
one
question.
You
know:
we've
been
kind
of
gating
some
of
these
other
api's
like
PHP,
to
wait
in
particular
for
Java
to
get
its
model
sorted
out,
but
I
wonder
if
we've
converged
enough
on
a
simplified
model
that
we
don't
need
to
necessarily
be
waiting
any
longer
to
attack
these
other
api's
I
mean
there's
a
certain
amount
of
bandwidth
and
availability.
B
Without
in
process
context
propagation
in
place,
we
cannot
instrument
common
frameworks
like
RTC
frameworks
like
HTTP
ions
yeah.
That
will
make
the
instrumentation
way
more
difficult.
I
will
say
that
I
would
rather
prefer
to
have
that
in
place
before,
like
I
could
now
bribe
meter,
whirs
and
HTTP
clients
for
this,
but
without
in
process
con
this
propagation
define
it
I,
don't
think
anyone
will
adopt
the
PHP.
A
B
Yeah,
that's
one
alternative,
I
I
haven't
had
time
since,
like
when
the
pull
requests
came
up
and
now
I
haven't
had
time
to
actually
the
decay
time
to
write
implementation
and
but
that's
another
alternative.
Like
I
know,
there
are
two
or
three
guys
very
eager
to
provide
a
jeager
implementation
for
PHP
and
that's
the
piece
they
are
lacking.
Basically
so
yeah
I
think
we
could
do
that.
That's
doable.
A
B
A
A
B
B
The
good
part
about
these
two
guys
that
have
mentioned
about
the
beginning
is
that
they
were
very
experienced
with
the
language,
so
their
comments
were
really
idiomatic
and
also
Benjamin.
Everly
is
a
vendor.
Kids
are
I,
the
one
run
in
tight
ways,
so
it
was
also
great
to
have
the
experience
from
one
vendor.
Besides
that,
it's
just
people
eager
to
do
implementations
and
yeah,
and
maybe
if
we
could
have
like
some
more
feedback
from
vendors
like
Curie
that
sometimes
contribute
to
open
question
PHP.
A
B
So
I
I
was
curious
because
I
really
believe
that
there
are
lots
of
people
with
PHP
mono
leads
and
they
are
probably
trying
to
split
it,
and
for
that
they
might
need
tracing.
That's
how
I
got
involved
in
tracing,
but
apparently
they
are
not
there
yet
or
they
already
split
it.
There,
monoliths
I,
don't
know.
What's
going
on
actually
chicken-egg
once.
B
B
I
think
one
bar
here
is
that
usually
PHP
host
teams,
they
provide
a
server
but
like,
if
you
wanna,
for
instance,
run
Zipkin
in
your
own
instance
and
it's
a
shared
server.
Then
they
will
make
it
right.
They
need
something
like
array,
their
data
dog
or
a
their
AWS
x-ray,
and
maybe
that's
not
popular
enough,
maybe
I'll
media
every
day
once
they
they
know
it
and
they
will
ask
for
it.
A
E
Well,
I
was
taking
a
look
at
that
at
the
API
that
they
are
having,
so
it's
so
yeah.
Basically,
they
had
around
API
for
tracing,
so
I
was
thinking.
This
is
something
I
mentioned
in
some
in
some
of
the
discussions
in
the
session.
For
a
point
said,
we
could
try
out,
maybe
provide
a
grant
of
what
they
are
doing
just
to
prototype
stuff,
because
I
think
at
the
moment
there
are
no
vendors
who
have
like
an
actual
tracer
for
Fisher.
E
E
Sadly,
for
me,
I
mean
I
have
60
charts,
but
sadly
for
me
you
know:
I
am
a
little
bit
busy
with
other
stuff
like
Python
and
Java,
so
but
yeah,
but
at
least
for
me
so
I
can
take
a
deeper
look
after
I
have
more
time.
I
think
I
think
Christian
kinder
left
the
project
he's
still
around,
but
he
stopped
putting
some
effort
into
that
so
yeah.
Maybe
we
can
find
a
way
to
make
him
interesting.
J
Yeah
for,
for
the
dog
point
of
view,
I
mean
we
are
interested
about
that
the
topic.
Definitely
eventually,
we
will
have
a
sister
betrayal
by
the
way,
so
it's
very
interesting
to
move
sooner
than
later,
and
there
is
Bertrand
that
was
that
was
the
task
get
to
Christian
about
some
feedbacks
and
also
the
current
state,
and
actually
he
is
working
with
us.
So
what
would
be
great?
He
is
getting
more
ya
know
if
there
are
other
people
that
are
interesting
about
that
and
if
you
Carlos
at
some
point
he
will
start
working
on
it.
J
Just
I
mean
I
think
that
it
would
be
great
for
us
for
everyone
if
we
start
collaborating
around
C
sharp
so
that
we
can
push
things
forward.
We
basically
what
we
did
was
providing
a
poor
request
just
internally
just
to
see
okay,
how
will
be
the
API
if
we
use
the
same
approach
of
Java?
It's
something
we
can
just
push
is
someone
who
just
want
to
take
a
look,
but
it's
the
goal
here.
J
Yes,
it's
first
discussing
about
this
new
Microsoft
thing,
of
course,
and
how
things
can
be
improved,
but
definitely
I
mean
we
are
investing
for
20
I
can't
provide
more
details
because
I'm
noticing
sharp
expert
and
their
son
is
not
available
today,
but
definitely
I
mean
whenever
we
will
have
more
details.
We
can
of
course
share
all
of
that
with.
A
Great
c-sharp
TBD,
but
it
sounds
like
at
least
data
dog,
Carlos
and
hopefully
Christian
Weiss
and
a
couple
other
people.
If
we
kind
of
get
enough
of
a
you,
know,
Colonel
of
activity
going
around
that
API
I.
Imagine
other
people
we
wouldn't
want
to
hold
it
down,
but
would
be
happy
to
contribute,
would
would
start
showing
up.
So
that
would
definitely
be
useful.
Maybe
in
January
we
can
get
that
started.
A
A
M
Yeah,
it's
sort
of
half
functional
yeah,
not
too
much
to
say
that
people
haven't
heard
you
for,
but
seems
well
actually
Ted
you're,
the
one
who
should
get
most
of
credit
for
this.
But
there
has
been
a
bunch
of
activity
with
the
various
service,
natural
and
technologies
or
committing
token
tracing
one
form
or
another.
With.
M
I'm
sorry
I'm
there's
going
to
be
a
support
and
sto
itself
in
addition
to
the
Envoy
support.
That's
already
there
broken
tracing
and
there's
already
this
more
convention,
X
and
so
on.
So
I'm
going
to
be
doing
this
talk
at
tubecon
phonetic
on
that
will
certainly
like
feature
a
basic
story:
announce
service,
mash,
the
basic
story
around
token
tracing
and
then
explain
how
they
make
each
other
better
and
that
sort
of
thing.
So
hopefully
it
will
generate
like
some
interest
and
we're
going
to
be
doing
a
little.
M
Like
brief,
saying,
I'm
at
claims
envoy
workshops,
one
thing
and
vice
versa
in
ours
and
I
just
seems
like
it's.
It's
a
topic.
That's
getting
a
lot
of
attention
for
a
good
reasons.
Lately,
and-
and
it's
also
something
I
think
open
tracing-
has
a
really
nice
story,
because
I
think
there's
a
misconception
that
you
can
trace
the
surface
mesh
layer
on
its
own
and
then
be
done
with
tracing
I.
Don't
think!
M
A
A
These
service
mesh
technologies-
they
don't
want
to
compile
in
every
single
flavor
of
tracer
out
there
right,
like
you,
know
the
number
of
dependencies
that
would
come
in
if
they
even
try
to
do
that,
would
really
become
burdensome
to
them,
and
then
they
would
become
sort
of
downstream
part
of
your
your
downstream
for
both
updates
to
their
technology
and
any
sort
of
tracing
plug-in.
That
shows
up.
A
We
had
something
similar
with
things
like
you
know:
volume
providers
like
storage
providers
in
kubernetes,
so
the
fact
that
open
tracing
gives
you
a
standard
API
opens
the
door
to
being
able
to
sort
of
link
in
your
tracer
as
a
as
a
linked
plugin,
especially
for
these
C++
implementations
and
I.
Think
that's
that's
one
of
the
reasons
why
it's
it's
taking
off
in
that
space.
A
G
In
there,
but
I
think
the
things
that
might
be
most
interesting
for
people
on
this
call
are
so
I
guess.
Our
tracing
model
is
slightly
different
than
the
open
tracing
one.
Rather
than
doing
a
parent-child
span
relationships.
We
have
explicit
sort
of
blocks
which
are
intervals
in
time,
points
which
are
instance
in
time
and
then
edges
that
connect
them
together,
and
so
we
can
represent
sort
of
dag
based
structures.
We've
used
it
to
record
the
continuation
flow
within
our
HH
p.m.
G
PHP
execution
engine,
as
well
as
things
like
capturing
stack
samples
from
periodic
profilers
kind
of
tied
in
to
some
of
the
discussion.
From
earlier.
We
we
have
a
decoupling
of
how
we,
the
instrumentation,
that
is
wired
into
code,
generates
events
which
are
then
reconstructed
into
a
trace
later.
This
kind
of
ties
into
I
think
to
the
versioning
discussion
earlier
in
the
Java
API.
G
You
know
version
of
any
tracing
API,
and
so
we
use
this
as
a
form
of
backwards
compatibility,
and
so
we
can
reinterpret
events
and
structures
from
old
versions
of
the
trace
of
old
version
of
the
library
to
map
into
any
newer
changes
we've
made,
and
there
was
one
more
thing
that
I
wanted
to
bring
up,
but
I
forgotten
it
by
now.
But
in
any
case,
if
people
have
any
questions
or
you
have
to
reading
it,
any
thoughts
or
feedback
as
well
I'd
be
happy
to
talk.
A
G
Isn't
hat
there?
Isn't
it
there
isn't
a
place
right
now?
If
they
want
I,
guess
they
can
contact
me
directly
and
I
can
put
them
in
contact
with
either
other
people
on
the
team
working
on
it
or
if
there's
sufficient
interest,
/
sufficient
number
of
people
have
questions
possibly
on
the
next
call.
I
could
take.
You
know,
answer
a
few
of
them
in
line,
but
yeah.
We
should
probably
also
set
up
a
like
a
discussion
forum
or
something
for
it
as
well.
I.
M
Would
love
to
hear
more
about
this
myself
and
I?
Think
if
I
like
the
most
is
that
it's
actually
not
that
similar
as
the
other
places
out
there
there's?
Definitely
something
I
hear
some
people
sometimes
like?
Oh
well,
you
know
we
should
just
like
have
everything
be
you
know.
Basically,
the
model
from
dapper
is
akin
and
and
I've
always
felt
like
that
model
was
actually
kind
of
insufficient
in
many
ways
and
they
either
because
it's
not
descriptive
enough,
where
it's
not.
M
It's
not
adaptable
enough
to
the
heterogeneity
of
data
out
there
and
and
I
think
one
of
the
one
of
the
most
interesting
aspects
is
what
you
all
have
done
with
canopy
is
to
is
to
build
something
that
actually
doesn't
map
one
to
one.
The
data
model,
data
modeling
standpoint,
so
yeah
I,
think
I'd
be
really
great
to
understand
more
especially
the
motivations
behind
some
of
the
data
model
stuff
from
a
practical
kind
of
getting
into
production
standpoint,
at
least
for
me.
Okay,.
G
Yeah
I
mean
I,
think
and
I,
so
that
wasn't
the
third
point
that
I
had,
but
one
of
the
things
that
we
found
is
that
we
actually
need
to
evolve
our
data
model
over
time,
as
we
find
that
there's
more
either
more
structure
that
we
want
to
represent
within
traces
or
more
information
that
we
want
to
capture
in
some
general
way.
And
so
this
is
let
us
sort
of
you
know.
We
don't
have
to
feel
committed
to
a
particular
model.
G
We
can
reinterpret
the
Tres
day
that
we've
got
to
cast
up,
cast
it
into
newer
forms
of
the
model
over
time,
which
is
definitely
been
useful
because
it
has
allowed
us
to
roll
out
newer
versions
of
library
without
revisiting
all
of
the
RPC
instrumentation
and
all
of
these
services
that
unfortunately,
have
not
been
deployed
or
redeployed
or
updated
in
years,
which
happens
to
us
all.
The
time.
A
Awesome,
alright,
well,
people
get
a
hold
of
Johnson,
Kaldor
and
I
believe
also
at
Johnson
base
who's.
Not
the
call
earlier
worked
on
that
system,
so
I'm
sure
he'd
be
happy
to
talk
to
people
about
it,
and
on
that
note
we
are
out
of
time.
I
just
want
to
give
one
shout
out
to
Jose
Carlos
who
I'd
we
put
up
a
question
about
templates
for
issues
in
PR
Jose
Carlos
I
would
recommend
just
making
an
issue
against
the
github
specification
repo.
B
Yeah
so
yeah,
that's
basically
it
so
just
30
seconds
explanation.
Sometimes
we
get
some
issues
in
the
PHP
API
and
they're
more
like
specification
issues.
So
the
way
we
solve
it,
the
problem
was
to
create
an
issue
template
and
a
fear
template.
So
we
could
go
the
ride.
Issues
in
the
right
place
and
same
for
PRS
like
a
PR,
cannot
get
a
PR.
Actually,
if
you
don't
fulfill
all
these
requirements
and
improve
the
flow
of
communication
across
contributors
will
be
nice
to
scan
IDs
across
other
open
tracing
languages
yeah.
So.