►
From YouTube: OpenTracing Monthly Call 2018-01-05
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
Okay,
good
ready,
welcome
everyone
to
new
year
I'll.
Kick
this
o
TSE
call
off.
My
name
is
Ted
young
I
worked
at
light
step
and
spend
a
lot
of
time
contributing
to
the
open
tracing
project
since
there's
no
uniform
list,
I'm
just
gonna
call
people's
names
out
and
go
around,
and
you
just
say
a
little
thing
about
who
you
are
and
a
one-sentence
about
your
relationship
to
open
tracing
that'd
be
great.
So,
let's
start
with
Manu
hello.
B
C
A
E
F
A
H
A
I
A
A
So
let's
kick
it
off.
We've
got
a
couple
brief
updates
about
languages.
The
Java
API
is
about
to
go
out,
so
it's
just
been
a
little
bit
of
time.
Talking
about
that,
it
would
be
great
to
get
a
Python
update
from
Manu
and
then,
after
that,
what
I
would
like
to
do
with
this
particular
call,
since
there's
nothing
else
on
the
agenda
is
to
just
sort
of
have
a
roundtable
discussion
about
a
couple,
bigger
issues,
around
project
structure,
with
language,
maintainer,
x'
and
then
a
sort
of
dynamic
linking
issue
that
I
can
get
into.
A
So
hopefully
we
can
save
at
least
30
minutes
for
those
those
two
topics
together,
but
to
just
start
it
off
with
the
Java
API,
that's
a
pretty
big
deal.
A
lot
of
work
went
into
that
and
I
believe
we're
now.
Finally,
finally,
finally,
at
the
end
there's
a
single
sort
of
patch
issue-
that's
outstanding
right
now,
which
I
should
link
to,
but
that
involves
just
having
old
baseband
as
a
sort
of
stub
stub
interface,
which
was
solving
some
like
dependency
circles.
I
think
URI
was
having.
A
D
Unfortunately,
so
it's
it's
kind
of
nasty.
It's
for
people
to
discover
that
at
runtime,
even
though
let's
say
they
upgrade
like
either
Jaeger
or
open
tracing
API
and
then
suddenly
close
up
on
some
other
library
so
like.
Why
simply
introduced
in
this
interface
as
a
dynamic
class
that
seemed
to
solve
that
issue.
Okay,.
A
Yeah
I
felt,
like
I,
wasn't
strong
enough
Java
programmer
to
really
grok
how
how
it
works
or
what?
What
about
the
dependence
between
something
to
do
with
something
to
baseband?
And
then
it
just
gets
upgraded
to
the
regular
news
fan
interface,
which
has
all
the
methods
it
was
looking
for,
and
then
it
works.
Is
that
kind
of
how
the
the
mechanism
here.
D
E
A
Let's
move
that
discussion
to
the
PR,
a
tab
and
from
here,
but
let's
try
to
get
that
in
or
otherwise
resolved
by
end
a
day
today
and
I
believe
that
that
is
the
last
issue
that's
been
raised
about
the
31
API
URI.
Do
you
feel
like
you
would
be
satisfied,
given
the
work
you've
been
doing
on
Jager
and
pouring
it
over
to
release
on
Monday?
If
we
put
this
in
yeah,
okay,
great
excited
guys
finally
made
it
okay
and
then
someone
attacked
on
a
single
point
here
about
a
update
for
controls
yeah.
It
was.
B
It
was
me,
and
mostly,
we
start
emigrating
all
or
Java
tracer
to
the
new
API,
but
because
in
the
Java
agent
we
are
using
of
interesting
content
modules.
I
saw
that
some
work
was
already
scheduled
and
Danna
to
ship
some
release.
Candidate
I
just
want
to
have
an
update
about
the
remaining
modules,
the
remaining
content
models
yeah.
What
is
the
plan
now
in
terms
of
time?
Of
course,
I
think.
A
We
need
to
to
just
any
sort
of
dovetails
with
the
language
maintain
its
discussion,
but
yeah.
We
need
to
just
make
sure
every
Java
instrumentation
we
can
find
it
gets
ported
and
possibly
leaves
a
tagger
branch
for
the
version
that
works
with
the
30
API
I
suppose
come
up
with
like
a
tag:
ot
V,
0,
30,
or
something
like
that.
So
people
have
a
consistent
way
of
being
able
to
find
that
older
one.
A
That
would
be
my
suggestion
for
how
we
do
it,
but
it'll,
mostly
just
be
I,
think
contacting
the
maintainer
x'
of
each
piece
of
instrumentation
and
asking
them
to
do
the
work
or
you
know
doing
the
PRS
themselves
from
some
the
the
core
groups
that
have
Java
staff.
Who
can
push
on
that?
But
that's
that's.
Basically.
It.
B
A
B
Currently,
ok,
because
of
Christmas
and
so
on,
we
didn't
spend
a
lot
of
time
doing
some
updates
I
just
went
to
the
action
items
for
the
next
week,
because
the
first
issue
is
that
we
didn't
have
a
lot
of
reviews
about
the
API
implementation.
Sorry,
the
API
specification
and
implementation,
and
just
from
ok,
of
course,
for
me
and
from
Carlos.
B
What
I'm
going
to
do
next
week
is
addressing
all
the
comments
from
Carlos
that
are
pretty
easy
at
the
very
this
state
would
be
great
if
someone-
maybe
people
that
are
in
this
in
this
meeting,
interesting
about
token
tracing
Python.
If
we
can
have
some
feedback
about
that
because
for
us
actually
it's
working
internally,
we
are
already
using
a
part
of
it
for
some
services,
not
everywhere
and
yeah.
Having
more
feedbacks,
we
would
be
great.
B
D
A
A
Alrighty,
unless
people
have
any
other
language,
API
questions
or
you
know,
sort
of
maybe
greedy,
they
won
that
discuss
I'd
like
to
move
on
to
a
couple
of
loser,
roundtable
discussions.
So
just
one
last
call
does
anyone
have
any
sort
of
day-to-day
business
they
want
to
make
sure
they
get
done
at
this
call
today.
A
A
I've
been
kind
of
calling
this
a
language
maintainer
role,
but
to
describe
just
sort
of
the
issue
that
I
see
I
think
there's
just
a
sprawling
amount
of
stuff
involved
in
open
tracing,
because
it's
just
a
huge
project
that
spans
all
of
the
languages
and
there's
very
few
people
who
have
broad
expertise
that
is
cross
all
of
these
languages.
So
one
way
to
divide
up
the
work
that
makes
a
lot
of
sense
is
to
sort
of
divide
it
up
by
language
with
the
language.
Api.
A
Issues
in
PR
requests
around
changes
to
that
and
then
sort
of
maintaining
the
ecosystem
around
the
instrumentation.
For
that
language,
not
necessarily
doing
all
of
the
work,
but
at
least
sorting
to
kind
of
have
a
set
of
people
who
are
kind
of
bottom
lining
and
making
sure
the
work
is
getting
done
and
then
there's
a
sort
of
set
of
maybe
structural
things
around
how
our
pull
requests
made
templates
for
issues
when
someone
makes
an
issue
have
a
template
to
start
off
with
if
an
issue
or
a
pull
request
can't
get
resolved
right
away.
A
What
should
we
do
with
that?
Should
we
create
milestones?
Should
we
close
those
issues,
etc,
etc?
There's
just
a
certain
amount
of
the
the
process
of
moving
through
these
issues
and
making
these
decisions
that
I
think
would
be.
If
there
were.
There
was
a
way
for
people
to
sign
up
to
kind
of
bottom-line
those
things
or
be
be
officially
part
of
it
or
a
way
to
identify
you'd
like
to
take
on
or
take
part
in
that
work.
A
I
think
that
would
help
encourage
people
to
kind
of
up
to
the
plate
and
it
would
be
great
to
start
creating
some
working
groups
around
those
kinds
of
issues,
rather
than
just
use
this
OTS
ccall
to
deal
with
some
of
those
nitty
gritty
project
details.
So
that's
the
the
kind
of
vague
thing
I
feel
like
this
project
could
use
right
now
and
I'm
curious
one.
A
B
Okay,
so
wellthey
Desai
I
was
thinking
some
days
ago
was
mostly
related
to
organizing
each
single
project
specification
or
the
basic
implementation,
so
that
issues
are
a
good
part
where
we
have
discussions
mostly.
So
we
already
talked
about
that.
But
I
want
to
to
push
that
topic
again
because
sometimes
okay,
we
have
language
containers,
so
let's
say
a
set
of
people
working
around
the
Python
API.
B
Let's
say
the
point
is
it
will
be
greater,
of
course,
getting
feedbacks
from
vendors
from
whoever
I
mean,
and
the
point
is
sometimes
we
get
discussions
on
glitter
and
sometimes
when
the
meaning
lists
it
depends.
My
media
was
what
do
you
think
if,
okay,
this
language
containers
are
also
kind
of
moderator,
so
github
issues
were
discussion.
Technical
discussions
happen
instead
of
detailed
material
so
having
the
repository,
the
source
of
truth
of
truth
about
the
development
of
new
features
or
feedbacks
or
stuff
like
that.
A
Yeah
I
certainly
like
the
idea
of
making
sure
there's
some
official
channel
for
where
these
discussions
are
happening
or
in
general,
being
able
for
people
in
the
community
to
be
able
to
find
the
discussions.
I
think
that's
an
issue.
I,
don't
know
if
github
issue
I
mean
I,
think
get
up.
Issues
are
a
great,
are
a
place
to
discuss
it
in
a
good
place.
They
still
there's
still
this
sort
of
it.
A
It's
like
how
can
we
pave
over
those
issues
and
kind
of
like
the
issues
with
the
issues
to
sort
of
make
sure
when
people
land
and
open
tracing
they
can
also
find
those
discussions.
So
I
guess
it's
I
would
just
add
on
to
their
it's,
not
just
MA
during
the
discussions
but
making
sure
people
the
community
are
aware
of
them.
Having
some
channel
for
for
getting
the
information
out
there
I
think
we've
discussed
that
before
having
an
update
section
on
the
website,
or
maybe
just
a
regular
blog
post
or
something
like
that.
D
What
kind
of
classes
of
issues
do
you
see
classes
of
issues
because
you're
usually
the
like,
for
example,
on
the
specification?
We
have
issues
for
quite
a
while
having
to
do
with,
let's
say
a
new
reference
type
or
this
debug
ID
yeah,
they
kind
of
linger
and
it's
hard
to
see
what
we
can
about
them.
But
a
mother,
you
should
seem
to
be
resolved
fairly
quickly.
D
A
I
think
some
some
issues
can
get
resolved
quickly.
Some
other
issues
either
something
seemed
they
seem
to
come
in.
A
couple
classes
like
this
seems
like
a
good
idea,
but
we
can't
agree
on
a
solution
or
maybe
it's
a
good
idea
that
people
aren't
fully
convinced
yet
and
in
particular,
there
are
I
think
some
pull
requests
and
issues
where
some
people
say
hey.
A
This
would
be
nice
and
other
people
say
yeah
I,
don't
know
about
it
and
then
it
just
sort
of
trails
off
right
and
part
of
that
is
I
feel
like
people
don't
know
who
has
what
authority
or
what
the
mechanism
actually
is
to
resolve
debates
like
that
or
where
they
should
go
at
that
point.
So
just
having
at
least
to
my
mind,
some
amount
of
responsibility
placed
on
some
people
where
you
can
at
least
say
hey,
because
this
is
Java
and
let's
say
Carlos
Alberto
is
you
know
a
job,
a
language
maintainer.
A
You
can
say
like
assign
him
to
that
issue,
and
then
it's
his
responsibility
to
to
keep
poking
the
people
to
get
them
to
agree
or
if
they
really
can't
agree
to
have
some
way
of.
Like
then,
closing
that
issue
or
discussion
down
by
saying
like
looks
like
we've
gotten
as
far
as
we
can
get,
this
is
like
the
final
state
where
this
landed
and
now
we're
going
to
to
put
this
in
someplace
where
people
can
find
it
if
it
comes
up
again,
but
we're
not
talking
about
it
actively
anymore.
D
So
a
couple
things
I
think
we
might
want
to
introduce
some
taxonomy
of
labels
in
this
case,
I
think
we
need
to
decide
like
if
the
issue
reaches
a
point
where
no
one
is
convinced
or
something
or
there's
like
basically
disagreement,
and
we
don't
want
to
do.
We
want
to
close
it
or
do
we
want
to
just
Park
it
and
label
it
part
until
further.
D
That's
one
another
thing:
I
think
we
should
add
code
owners
files,
then
into
all,
and
then
the
third
one
is.
This
is
something
we
do
in
a
a
tuberous
part
of
our,
like
my
team
or
key
ours.
We
will
have
usually
under
key,
are
like
response
to
open
source
stickies
within
two
days
right,
like
an
SLA
sort
of.
D
F
Yeah,
you
know,
from
my
perspective,
we're
just
kind
of
getting
started
with
open
tracing
and
there's
really
two
things
that
I
think
cause
a
little
bit
of
like
caught
like
clean
slate
confusion.
The
first
is
sometimes
it's
difficult
to
tell
where
a
specific
language
implementation
is
at
compared
to
the
spec,
and
to
do
that
right
now,
I've
had
to
kind
of
like
dig
through
issues
and
make
kind
of
assumptions.
I'm
not
always
sure,
are
correct
and
the
second
is
sometimes
the
you
know
for
a
vendor
or
for
for
someone
else.
F
If,
when
they
want
to
build
on
open
tracing
that
there,
there
could
be
some
concern.
When
you
see
a
number
of
lingering
issues,
because
you
know
open
tracing,
is
evolving,
there's
gonna
be
bugs
and
language-specific
implementations,
but
if
it
looks
like
there's
like
a
critical
one,
that
would
impact
how
our
agent
works,
which
then
bubbles
down
to
our
customers,
then
there's
some
some
concern
on
how
quickly
our
critical
things
address
and
I
think
is.
F
A
I
A
A
Cool,
that's
that's
good
and
I.
Think
part
part
of
that,
maybe
is,
do
you?
Would
you
if
there
is
a
prominent
location
that
explains
like
you
know,
these
are
the
maintainer
x'
for
various
languages
or
whatever,
or
you
know.
Basically
a
directory
of.
If
you
have
questions
here,
are
the
people
who
will
respond
to
them,
I,
don't
know
what
and
maybe
what
how
to
contact
them
like
what
is
a
communication
mechanism?
Would
that
be
a
kind
of
thing
you
would
use?
If
you
saw
something
like
that,
would
you
do
some
reach
out
yeah.
F
A
A
D
Well,
typically,
you
do
need
the
list
of
maintain
official
maintainer,
that's
what
code
owners
kind
of
comes
in
place
and
they
usually
in
all
projects,
have
the
final
say:
I
mean
so
far.
We
we
kinda
delegated
this
to
the
to
the
spec
Commission
right,
but
definitely
people
on
that
list
are
not
necessarily
experts
in
all
languages,
so
I
think
code
owner
is
slightly
different
and
that's
the
actual
maintainer
of
the
repo
and
like.
D
A
D
And
we
may
like,
rather
than
duplicating
with
no
the
each
each
ripples,
we
probably
should
consolidate
it
into
like
the
actual
project.
Governance
consolidated
in
the
stacks
reaper
just
make
sure
that
again
it
applies
to
individual
languages
differently
in
terms
of
like
who
are
the
people
right,
because
the
the
actual
people
will
be
in
the
code
owners
in
that
report.
A
I
almost
wonder
if
we
need
a
sort
of
so
right
now,
it's
I
think
if
someone
says
hey
I
want
to
do
this.
It
would
be
great
if
we
didn't
need
too
much
of
a
formal
voting
process.
Someone
who
had
sort
of
administrator
privileges
just
can
say
yeah.
You
know
if
you
can
convince
anyone
who
has
those
privileges,
that
you
seem
fine
for
doing
that
work,
then
they
could
add
you
rather
than
having
to
wait
for
some.
You
know
TSC
meeting
or
something
like
that,
but
it
makes
me
feel
like
right
now.
L
L
That
was
just
like
sitting
there
kind
of
dormant
for
months,
because
I
didn't
notice
it,
and
you
know
oh
well,
you
know
that's
a
terrible
situation
like
that.
That
should
never
happen.
So
to
me,
it's
like
just
having
someone
who's
on
the
hook,
just
making
sure
that
stuff.
Like
that
doesn't
happen.
It
was
pretty
much
as
easy
as
like
making
one
comment
and
then
merging.
It
was
a
difficult
PR
and
I
just
want
to
make
sure
that
we
have
someone
who's
responsible
for
that
for
just
keeping
track
of
that,
and
also
someone
who's.
L
As
you,
someone
said
earlier,
like
a
decider
for
issues
like
we
just
I,
think
there
are
a
lot
of
situations
that
I've
been
tracing
where
people
involved
in
this
project
are
usually
pretty
smart
and
reasonable,
which
is
great.
So
it
would
be
nice
if
someone
just
had
decision-making
authority,
even
if
the
decision
is
to
put
something
off,
but
just
like,
so
it
doesn't
end
up
in
the
state
that
is,
and
now
where
you
have
some
issues
that
they're
not
going
to
be
resolved.
L
I
L
A
A
We
should
just
think
a
little
bit
about
like
you
know.
What
are
we
gonna
put
on
the
website
around
if
like
to
be
take
on
this
role?
You
know,
how
do
you
raise
your
hand
and
say
I
would
like
this
and
then
who
says:
okay,
fine
you're
on
the
list,
so
yeah
just
think
a
little
bit
about
what
that
that
process
would
look
like
building.
L
L
A
L
L
A
And
for
the
contributes,
I
agree,
that's
where
probably
the
most
like
the
biggest
issue
around
like
people,
making
a
pull
request
or
an
issue,
and
did
it
like
not
getting
responded
to
is
probably
much
greater
there
than
in
the
language
repos.
Just
because
there's
so
many
more
contribute
bows
and
there's
this
issue
of
well,
there's
always
going
to
be.
You
know,
whoever's
the
sort
of
maintainer
for
that
thing,
but
you
know
people
kind
of
come
and
go
I.
A
Think
people
might
might
love
a
big
open
source
project
that
they're
working
on
and
like
devote
their
life
to
it.
But
if
it's
just
some
piece
of
instrumentation
for
some
library
that
you're
using
at
some
point
in
your
career,
you
should
kind
of
expect
people
who
who
write
those
things
will
then
move
on
and
the
maintainer
z'
of
those
instrumentations
will
have
to
like
change
over
time.
And
so
that's
sort
of
where
I
see
things
like.
You
know
the
de
st.
A
L
D
A
And
if
those
essays
are
easy
for
people
to
find
when
they
make
PRS
or
issues,
then
that
just
lets
them
know
when
they
have
a
question
they
can
at
least
know
like.
Oh
I
was
supposed
to
get
someone
assigned
to
this
two
days
ago.
So
I
now
feel
empowered
to
like
go
like
raise
this
to
somebody
and
I
can
see
on
the
list.
Who
I
should
ask
like
hey?
F
A
L
I
actually
be
I'm,
not
gonna,
put
you
on
the
spot,
but
it'd
be
great
to
hear
from
people
specifically
at
New,
Relic
and
and
the
folks
who
have
previously
spent
time
in
a
Vanetta
who
are
on
this
phone
stuff
to
understand
how
just
from
organizational
standpoint,
language
maintenance
work
for
the
agents.
I,
don't
think
it's
not
the
same
thing
when
we're
not
writing
agents
here,
but
it
reminds
me
of
that,
where
you
probably
have
some
common
data
format
and
model,
and
then
you
have
teams
tipping
of
stuff.
L
I
bet,
there's
some
similarities
in
terms
of
the
way
that
stuff
is
structured
and
if
there's
some
kind
of
like
TLDR
lessons
learned
like
don't
do
this
way.
Do
it
this
way
kind
of
thing
about
just
how
to
structure
the
per
language
stuff
in
conjunction
with
some
larger
data
model
that
that
crosses
between
languages?
L
F
F
One
thing
that
would
just
might
be
really
helpful
for
the
contribs
in
the
readme
is
like
for
Python
Django,
like
which
Python
version
was
as
tested
against
was
just
saying
was:
Django
version
was
just
tested
against,
just
because
I
think
what
can
happen
is
someone
might
start
trying
to
use,
though,
can't
rip
those
controls
and
if
they
start
having
a
pretty
bad
experience
like?
Oh,
it
doesn't
work
for
Python,
3
or
I'll
shoot
this
mode
for
this,
but
it
wasn't
clear
and
then
they
had
that
same
experience
in
other
languages.
F
G
From
neural
X
perspective,
this
is
very
similar,
you're
right,
there's
a
lot
of
parallels.
One
of
the
things
that
I
wrestle
with
currently
is
my
job
is
to
try
to
aim
for
consistency
across
all
of
our
agents
and
one
of
the
things
that's
the
most
helpful
for
me
is
just
being
able
to
track
inconsistencies
where
they
occur.
These
leakages
agents
have
been
built
over
years.
G
J
E
You
know,
client
implementation
is
always
going
to
report
method
and
status
like
that.
That
really
helps
you
kind
of
downstream.
So
from
a
vendor
perspective.
I
think
one
of
the
things
that
helped
us
at
least
you
know,
try
to
get
uniformity
as
you.
Basically,
these
internal
spec
documentation
about
like
if
you
want
something
to
show
up
as
like
an
HTTP
client,
then
you'd
better
capture,
these
things
and
then
there's
certain
optional
extensions
of
that.
But
there's
like
a
minimum
bar.
E
So
that's
you
know,
I
think
the
kind
of
semantic
specification
might
turn
into
a
guideline
for
that
in
terms
of
organization.
We
basically
have,
like
you
know,
one
direct
code
owner
that
is
in
charge
of
kind
of
the
internals
implementation
of,
and
so
that's
gonna
vary
from
from
runtime
to
runtime
or
language
language.
There
might
be
other
people
who
are
contributing
to
that
and
then
there's
there's.
E
You
know
it's
all
kind
of
obeying
that
broader
kind
of
semantic
spec
and
that's
a
little
bit
more
like
a
commis
like
a
wire
protocol,
type
view
of
things
that
open
tracing
doesn't
really
have
the
kind
of
luxury
of.
But
you
know
it's
almost
like
if
you
just
view
it
as
the
API
is
like
the
wire
protocol,
but
like
one
step
higher,
then
it's
really
really
similar
and
then
I
guess.
Lastly,
to
the
versions
things,
that's
definitely
a
huge
problem,
and
so
we
have
these
kind
of
like
matrix.
E
You
know
testing
things
where
it's
like
run.
You
know
these
versions
in
line
with
like
these
versions
and
basically
like
I
guess
with
contribs
I'll
you'd
almost
want
to
pull
those
into
your
build
and
like
run
those
on
your
matrix
to
figure
out.
You
know,
what's
gonna
work
on
Python
2
versus
Python,
3
and
so
on,
but
it's
it
the
challenge.
Automation
is
probably
by
the
best
way,
to
keep
track
of
it,
because
stuff
will
go
still
fast.
I.
E
A
Okay,
great,
that
was
I,
think
a
great
set
of
issues
and
targets
for
what
this
role
should
be.
That
was
raised.
I'll,
try
to
take
this
and
synthesize
it
into
a
document
and
make
a
github
issue
out
of
it
on
this
specification
repo
in
the
next
couple
of
days
but
yeah,
and
if
anyone
else
is
interested
in
collaborating
on
this
work.
A
Of
course,
see
me
the
issue
or
you
know,
contact
me
gator
alrighty,
so
we
only
have
a
little
bit
of
time
left
about
ten
minutes
or
so
and
I
just
wanted
to
first
raise
some
awareness
about
another
front,
opening
up
on
the
open
for
the
open
tracing
project
which
is
around
dynamic
linking
so
this
is
really
kind
of
started
with
service
meshes
and
proxies,
such
as
envoy
in
particular,
but
also
nginx,
linker,
D
and
other
pieces
of
software.
That
essentially,
are
what,
in
the
past
I've
called
network
appliances.
A
These
are
pieces
of
software
that
generally
you're,
not
writing.
You're.
Just
deploying
and
you'd
like
to
have
the
tracer
that
you
use
trace.
What's
going
on
in
these
things,
because
they're
often
in
band
with
the
requests
going
through
your
system,
kubernetes
ingress,
another
example
of
where
this
shows
up
and
in
all
these
cases
you
have
a
sort
of
way
of
getting
that
code
distributed
to
you.
That
is
not
that.
You
are
then
mutating
that
code
and
compiling
it
yourself
right.
A
And
so
what
is
looking
more
and
more
interesting
on
that
front
is
some
form
of
dynamic,
linking
where
perhaps
there's
some
kind
of
set
of
some
set
of
tracers
that
are
baked
into
these
things
by
default.
But
if
you
roll
on
boy
out,
for
example,
you'd
like
to
then
dynamically
link,
Jaeger
or
light
step
or
New
Relic,
or
something
like
that
into
into
envoy
at
runtime
and
to
have
to
distribution
channels
for
how
you're
deploying
these
things
and
getting
them
onto
your
machine.
A
So
that
that's
the
thing
that's
that's
coming
up,
as
we
start
to
get
more
and
more
integrated
with
the
sort
of
infrastructure
layer
that
people
are
running
running
their
programs
on.
So
my
first
question
is:
does
what
I
just
said
make
sense
to
people?
I
should
clarify
for-
and
my
second
question
is
what
are
people's
experiences
with
this
kind
of
dynamic?
Linking
do
people
have
suggestions
for
deployment
models
for
this
sort
of
thing
in
this
new
sort
of
docker
image
world
that
we
live
in.
A
Problem
though,
right
exposed,
there's
one
part,
that's
language
specific,
which
is
the
the
three
languages
where
we've
kind
of
seen
this
come
up
so
far
our
C++
go
and
Java,
and
they
all
have
different
kinds
of
runtime
linking
mechanisms.
So
so
that
part
is
certainly
language,
specific
I,
don't
think
it
will
extend
beyond
those
languages,
maybe
rust,
but
that's
mostly
what
what
people
write
infrastructure
stuff
in.
A
So
it's
going
to
be
those
three,
the
part
that
does
seem
a
little
cross
language
is
there
some
wait,
there's
some
format
for
passing
configuration
to
the
tracer,
where
you're
going
to
write
some
kind
of
configuration
thing
in
you
know
as
part
of
your
configuration
for
envoy
or
or
link
or
D,
and
then
that
has
to
get
passed
over
to
the
tracer.
So
that
was
one
place
where
having
some
standardization,
that
was
maybe
cross
language
would
be
nice
as
well.
A
L
Interesting
to
me,
I
totally
agree
with
that
Ted
about
the
static
configuration
of
the
tracers
themselves.
Is
it's
interesting
because,
like
in
the
specification,
we've
struggled
the
times,
for
instance
with
the
idea
of
like
it's
I,
think
most,
if
not
all
like
real
tracer
implementations
have
some
tags
that
are
passed
to
the
tracer,
then
they
get
applied
to
every
span
or
something
like
that.
L
We
don't
have
a
place
to
like
really
refine
that,
because
the
the
way
that
trace
struck
configured
isn't
part
of
specification
is
this
kind
of
a
convention,
but
we
would
have
to
I
think
well.
It
would
be
beneficial
if
we
could
describe
things
like
that,
and
this
in
the
static
integration
for
tracers.
I
also
think
another
use
case
that
you
didn't
mention
that,
but
I
think
is
sort
of
interesting.
There's
a
like
I
think,
there's
a
false
dichotomy
between
the
open
tracing
approach
and
like
a
traditional
agent
that
reaches
in
from
the
outside.
L
It
is
possible
to
write
some
kind
of
agent
that
uses
open
tracing,
in
fact,
I
think
there's
some
kind
of
fledgling
project
in
the
jvm
world.
That
does
exactly
that.
But
configuring
something
like
that,
it
would
also
be
nice
to
to
be
able
to
plug
in
an
arbitrary
tracer
implementation.
Dynamically
and
and
I
mean
I
can
see.
I
can
see
other
applications
of
this
for
sure
beyond
just
infrastructure
software,
but
they
all
need
some
way.
It
would
be
great
not
to
have
different
configurations
of
these
tracers
from
language
to
language,
where
I
think
I'd.
L
A
L
A
But
it's
more
like
you're
gonna
get
a
blob
of
JSON
and
then
there's
going
to
be
like
this
key
and
then
all
of
your
trace
or
specific
stuff
will
be
off
of
that.
It
seems
like
there's
just
a
little
bit
of
that
I
linked
by
the
way
I
link
to
the
there's,
a
PR
for
this,
an
envoy
that
I
linked
to
and
the
notes,
but
I'll,
throw
into
the
chat
here
just
that
people
want
to
see
a
concrete
example
of
what
we're
talking
about
here.
D
D
Although,
like
with
the
config
file,
you
run
and
you
like
format,
issues
like
most
of
our
libraries
sort
of
either
punt
on
the
format
completely.
And
let
you
do
that
or
like
in
and
note
it
would
expect
like
a
dictionary
or
JavaScript
a
JSON
file.
Something
like
that,
so
that
that
part
of
standardization
is
a
bit
difficult.
But
that's
like
mostly
limited
to
to
the
individual
system
and
the
the
point
about
like
heaven,
is
sort
of
a
common
key
and
Android
configuration
that
seems
like
at
suggesting.
D
A
So
so
one
example
of
where
the
standardization
should
be
beyond
just
the
project
is
so:
let's
say
you
make
a
C++
tracer
that
could
be
dynamically
linked
and
envoy
offers
dynamic,
linking
to
C++,
tracers
and
then
nginx.
Open
tracing
is
an
open
tracing
module
that
also
offers
dynamic
linking
to
C++
tracers,
and
it
would
be
great
if
you
could
just
make
one.
You
know
C++,
tracer,
binary
or
tracer.
You
know
shared
object
file
and
it's
gonna
work
with
engine
X
with
envoy,
with
anything
else,
that's
doing
some
form
of
open
tracing.
A
You
know
dynamic
linking
so
there's
at
least
a
bit.
You
know
that
that's
where
I
see
the
standardization,
you
don't
want
people
having
to
write
a
dynamically
linked
engine,
X
plug-in
and
a
dynamically
linked,
Envoy
plug-in,
and
they
like
so
that's
sort
of
what
I
would
like
to
see.
I
get
standardized
and
then
the
other
question,
that's
just
sort
of
a
bigger
question
is
I'm.
A
Not
it's
not
totally
clear
to
me
what
the
best
distribution
mechanisms
are
for
some
of
these
things
like,
if
you
want
to
add
in
genetics,
ingress
if
you
want
it
that
has
in
genetics,
open
tracing
baked
into
it
now,
but
it
just
has
like
Zipkin
on
by
default
and
if
you
wanted
to
add
Jager
New
Relic
to
engine
X
in
grass
like
what
would
be
the
actual
mechanism
for
that.
That's
more
probably
kubernetes
to
decide
that
but
I'm
wondering
if
people
have
any
history
with
with
how
they
they
glue
these
things
together
at
deployment
time.
A
Anyways
food
for
thought:
that's
that's
a
sort
of
thing!
That's
just
starting
to
develop
right
now!
So
again,
if
that's
the
kind
of
thing
you're
interested
in,
say,
hi
and
get
er,
you
can
ping
me.
Ryan
Bern
has
been
working
on
this
stuff
at
the
sort
of
C++
level
and
Sergey
I
believe
was
just
starting
to
maybe
look
at
a
Java
version
of
this,
so
we
can
make
a
PR
against
linker
D
so
that
linker
D
could
support
open
tracing
in
Java.
M
L
Sweetie
yeah,
that's
true.
The
I
also
just
wanted
to
make
a
quick
plug
before
you
finish.
The
call
that
I'm
going
to
try
and
like
have
a
not
sure
if
it'll
be
this
color,
some
other
call,
but
some
scheduled
thing
in
advance
or
we'll
have
people
from
various
companies.
Not
vendors,
but
something's
using
tracing
doesn't
happy
open
tracing
talking
about
their
stuff
and
just
have
that
be
kind
of
a
rotating
calendar
like
half
an
hour
presentations.