►
From YouTube: CNCF OpenTracing Monthly Call - 2019-04-05
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A
Cool
well
to
kick
it
off.
There's
two
things
on
the
agenda:
one
is
just
you
know,
open
forum
around,
you
know
the
open
tracing,
open
census,
merger
I'm.
Sure
people
have
some
questions
about
that
and
then
more
specific
discussion
around
Java
33
kicking
that
out
quicker
to
get
a
clean
version.
That's
missing
all
the
deprecated
methods,
I'm
wondering
if
we
want
to
start
with
that
item
since
the
other
items
a
little
more
open-ended
and
I.
Think
I
saw
Tyler
hanging
out
I'm,
correct
stellar
on
the
call
deals.
A
C
B
A
A
Those
are
a
reason
I'm
just
curious,
which
is,
if
we're
about
to
move
to
a
new
project
and
that
new
projects
gonna
have
a
new
wait.
We're
gonna
have
like
a
seamless
transition,
or
at
least
a
you
know,
allowing
people
to
transition
to
the
new
SDK
without
having
to
totally
update
all
of
their
instrumentation.
All
at
once.
It
seems
like
deprecating.
A
bunch
of
methods
would
create
potential
like
migration
challenges
for
people.
A
D
A
I
think
that's
fair,
okay!
Well,
let's
switch
back
to
talking
about
this
merger,
so
there's
been
a
lot
of
interest
from
the
core
members
of
both
projects
to
merge
them
and
we'd
certainly
be
getting
cheered
on
by
everyone
else
to
make
it
happen.
So
I'm
super
happy
to
say
that
that's
going
to
happen,
we
made
an
announcement
last
week.
A
So
that's
the
plan
from
an
organizational
standpoint.
I,
don't
think
there
are
hard
dates
except
we're.
Looking
at
Q
con
Europe,
which
is
on
May
20th
as
like
a
nice
deadline
to
try
to
have
as
many
things
as
we
can
cleaned
up
by
then,
and
in
particular,
there's
technical
track.
Moving
right
now,
consisting
the
same
founders
to
try
to
get
a
combined,
API
and
prototype
written
in
Java
as
a
sort
of
like
alpha
release
candidate
for
everyone
else.
A
A
I'm,
just
gonna
push
that
into
chat
we're
trying
to
keep
the
the
github
issues
there
clean.
So
people
want
to
see
this
state
of
the
prod
project.
You
can
look
at
the
milestones
and
look
at
the
github
issues
and,
of
course,
feel
free
to
comment
on
them.
The
only
thing
we're
saying
at
this
time
is
there
are
some
core
committers
and
just
in
the
name
of
like
moving
quickly
to
something
that's
holistically
in
a
reviewable
state.
A
A
D
D
So
it's
a
tricky
thing
to
do
and
there's
still
work
in
progress
and
there's
also
work
going
on
like
what
you
name.
The
new
project
is
definitely
going
to
be
in
your
name,
but
what
it
is
is
still
undecided.
We,
we
think
enough.
I,
think
Xin
CF
actually
proposed
to
to
put
some
of
their
what
you
call
them
like
a
sort
of
consulting
services
into
figuring
out
what
the
best
name
and
the
trademark
and
the
logo
etc.
D
D
E
A
D
A
One
way
I
would
like
to
see
ramped
participation
ramped
up
in
the
process.
Open
up
is
getting
everyone
involved
in
reviewing
the
Java
API,
forming
some
kind
of
standard
spec,
with
the
standard
nomenclature
kind
of
what
we
did
and
open
tracing
and
then
going
to
town
on
all
the
other
language
ecosystems.
A
That's
the
part
where
I
see
this
as
being
just
a
heat,
lift
that's
gonna
need
the
whole
community
communities,
both
open
tracing,
no
consensus
communities
to
come
together
and
do
my
one
concern
is
just
getting
through
the
valley
between
having
existing
projects
that
work
in
production
and
this
new
project
that
we're
hopeful
about,
but
will
be
kind
of
like
vaporous
until
we
fill
in
all
the
different
languages
getting
their
api's
and
learning
correct
and
then
getting
kind
of
sdk.
You
know
standard
reference
implementation
in
there
for
each
language.
A
Another
concern
would
be
if
we
somehow
make
the
new
thing
backwards,
incompatible
with
the
old
thing,
so
that
migrating
is
difficult
and
we
pull
a
you
know:
Perl,
6
or
Python
3
moment
we're
really
dedicated
to
not
making
that
happen,
but
I
think
once
it
gets
to
like
making
this
whole
thing
go
and
like
13
different
languages.
That's
when
it's
gonna
be
a
huge
community
effort,
so
I
will
be
coming
around
and
asking
for
everyone's
time
as
we
get
closer
to
that
I
hope
to
see
you
there.
D
B
The
other
aspect
of
that
that
is
somewhat
beneficial
is
from
a
tracer
perspective.
In
theory
would
not
be
a
breaking
change.
It
would
only
be
a
breaking
change
for
the
the
author,
the
instrumentation
side,
and
so,
if,
if,
if
a
tracer
wanted
to
be
compatible
with
both
the
32
and
33,
they
could
just
leave
those
methods
where,
where
we
want
the
instrumentation
and
the
consumers
of
the
API
is
to
be
pushed
forward
and
not
maintain
and
continue
to
use
these
considered
harmful,
api's
yeah.
F
A
Think
that's
fair
I
do
think
we
have
an
out
also
if
it
turns
out
we've
like
totally
left
a
bunch
of
people
in
the
dust
you
can
go
ahead
and
implement
those
deprecated
features
in
the
bridge
to
the
new
project
and
put
them
in
some
way.
So
maybe
the
correct
thing
is
to
go
forwards
and
remove
everything.
A
B
A
Do
think
one
thing
we
want
to
be
careful
about
is
so
they're.
The
new
API
will
definitely
not
be
directly
compatible
with
the
old
ones.
If
for
no
other
reason
than
we're
we're
having
to
change
the
names
right
like
open,
tracing
and
open
census,
don't
use
all
the
same
words,
so
someone's
gonna
get
a
new
word
somewhere
for
something
so.
B
A
A
So
if
people
want
to
build
new
tracers
or
update
their
tracers
and
have
those
all
work
with
a
new
project,
I
would
love
people
who
are
using
old
instrumentation
to
be
able
to
adopt
that
new
SDK
and
that
new
interface
without
having
to
completely
throw
all
of
their
old
instrumentation
away.
In
that
moment,
I
think
being
able
to
like
adopt
the
new
implementation
but
then
progressively
transition.
Your
instrumentation
will
be
like
the
key
to
like
quickly
migrating
everyone
off
of
open
tracing
a
know,
consensus
and
into
this
new
project
off
the.
B
A
G
A
A
There's
no
proposed
timeline.
I
would
like
to
get
one
together.
I
really
would
like
to
get
a
sort
of
Gantt
chart,
at
least
of
just
you
know,
all
the
all
the
things
that
need
to
happen
in
each
language
and
then
see
if
we
can
get
kind
of
tackled,
get
a
team
together
per
language
to
kind
of
holistically,
tackle
that
language.
A
A
I
think
one
thing
that
is
different
about
the
new
project
that
I
do
like
is
taking
that
context,
propagation
and
making
that
open
census
works
more
like
that.
But
this,
but
having
the
contacts
propagation
be
like
an
underlying
layer
that
all
of
the
observability
rides
on
top
of,
rather
than
the
way
it
works
in
open
tracing
where
the
observability
spans
are
also
the
context
propagation.
A
What
propagate
other
things
you're
doing
that
in
baggage
on
spans
and
in
this
new
world,
there's
going
to
be
a
context,
propagation
mechanism
and
spans-
and
you
know
metrics,
and
all
these
other
things
are
sitting
on
top
of
it.
If
that
makes
sense,
and
you
can
get
I
would
encourage
people
to
go
check
out
that
repo.
If
they're
wondering
what
that
all
means.
C
F
A
A
F
A
Believe
there
was
discussion
on
the
open
census
side
around
adding
a
logging
interface
yeah
like
a
non
contextualized
logging
interface.
I
have
not
been
involved
directly
in
that
project.
Do.
D
By
the
way,
it
would
be
interesting
to
to
get
like
a
PM
vendors
to
take
a
very
close
look
at
the
metrics
part
of
open
census,
see
if
it's
efficient
enough
is
like
well.
I
ran
out
any
problems
with
that
one
I
mean
it's
not
going
to
be
I,
think
and
blogger
for
the
merge,
because
one
of
the
goals
of
the
nurse
is
that
we're
not
bringing
any
new
functionality
and
so
because
of
on
tracing
has
no
say
in
metrics.
D
We
can't
say
anything
and
in
your
project
in
migrate
directly
from
open
census,
but
going
forward
if
there
is
any
sort
of
feedback
etc,
because
definitely
it's
it's.
It's
a
it's
an
expensive
proposition
to
have
the
contextual,
metrics
versus
just
labelled
metrics
and
so
I'm
curious.
Whether
people
have
experienced
with
using
that
API.
B
D
The
more
like
a
baggage
tags,
so
you
can
I
think
if
you
think
in
terms
of
go,
you
now
have
to
pass
context
object
into
every
code
to
your
like
increment,
the
counter
right.
So
that's
has
some
performance
implications
like
in
Java.
It's
not
this
way,
but
it's
still
the
conceptually
your
metrics
are
not
just
labeled
by
the
static
labels.
They
can
also
pull
some
labels
from
the
from
baggage
effectively.
Okay,.
D
F
D
F
A
Do
think
one
related
issue
like
what
you're
just
talking
about
it's
just
in
general,
there's
a
lot
of
machinery
on
the
open
census
side,
which
is
like
nice
for
people
who
want
it.
But
you
know
I,
don't
it's
not
clear
to
me
that
everyone
wants
the
overhead
of
seepages
or
some
of
the
other
stuff
I
was
just
about
to
ask
when.
F
D
A
H
H
A
But
yet
so
I
think
part.
Part
of
this
is
the
new
project.
Will
work
open
tracing
style
in
the
sense
that
if
you
don't
like
this
default
implementation,
you
can
still
bring
your
own
and
your
own
doesn't
mean,
because
you
have
a
tracer,
you
know,
I
have
could
consume
metrics
logs
and
any
of
the
other
interfaces
that
are
in
there
it'll
be
possible
to
just
bring
your
own
tracer
implementation.
I!
Think
that's
what
you
want
to
do.
A
So
it's
also
not
the
case
that
everyone's
going
to
automatically
have
to
inherit
some
of
these
potentially
expensive
or
looking
features
and
over
in
the
open
census
side.
They
do
hope
everything
gets
to
the
place
where
we're
generally
using
like
some
standard
tracing
clients,
I.
Think,
there's
not
a
lot
of
reason
to
not
do
that.
If
there
is
I'm
curious
what
they
are,
but
will
still
be
possible
to.
B
A
A
G
I
just
joined
it
yeah
there
you
go
yeah,
sorry,
yeah,
so
basically,
I
think
the
important
change
for
helping
us
you
know
in
this
transition
is
actually
removing
this
scope
related
stuff
that
that
was
you
know
when
prototyping
this
bridge.
This
was
the
complicated
part.
You
know
so.
I
think
that
this
is
the
important
thing
we
need.
A
A
E
E
C
E
E
No
mainly
because
it's
it's
using
some
internal
hooks
in
node,
that
is
not
in
the
browser,
so
it's
not
really
compatible
this
implementation
that
we
re
adding
and
it's
it's
it's
like
the
way
you
solve.
This
is
different.
I
get
anyway,
so
it
there
yeah,
no
didn't
notice
a
special
case.
So
you
could
make
something
in
the
browser
that
would
also
work
in
node,
but
they
would
only
cover
the
browser
part
of
no
draw
or
the
the
the
core
part
of
JavaScript.
E
They
wouldn't
cover
all
the
node
API,
so
node
needs
something
special
anyway
and
that's
what
what
we
want
to
add
we're
also
looking
into
adding
a
proper
APM
API
to
note
I'm,
leading
that
that
effort,
but
it's
haven't
gotten
started
on
it
yet
so
so
there's
it's
so
up
in
the
air.
What's
gonna
happen,
but
we
want
to
to
make
sure
that
the
node
community
kind
of
depends
together
around
on
it
somehow
so
that,
if
you
are
writing
a
database
driver,
you
can
make
the
database
driver
easily
instrumental.
E
A
Don't
I
don't
know
how
the
timing
of
that
works
with
the
mergers
of
these
projects,
but
it
would
be
great
if
whatever
the
new
JavaScript
sting
comes
out,
at
least
a
node
version
of
we
could
be
great
to
have
you
involved
Thomas
and
make
sure
what's
happening
on
this
end.
Jives
really
well
with
what's
going
on
in
node
core.
I
Sorry
I,
just
during
the
college
and
this
conflict
earlier,
but
I
also
think
that
it
might
be
worth
pinging
the
people
on
x-ray,
like
the
Abhishek,
etc.
First
Gotham
merger
in
general,
and
also
one
of
the
places
I,
see
node,
use
a
lot
of
courses
in
lambda,
etc,
serve
Allah
stuff,
and
it
would
be
I
think
a
really
good
Anna
proof
point
that
a
simple
straight
forward,
node
lambda
stuff,
like
just
works
with
all
this,
would
be
like
a
really
amazing
kind
of
like
a
litmus
test.
I
C
A
B
I
Think
that
they
will
support
it
precisely
when
their
customers
demand
that
they
do
and
no
sooner
I
think
that's
the
sense.
I.
Don't
think
that
there's
some
sort
of
master
plan
to
create
a
competing
standard
or
anything
like
that
they've
seemed
very
happy
to
just
see
what
the
market
decides
and
let's
do
it
that
that's
my
sense
of
there
I
mean
I'm
speaking
for
them,
obviously,
and
I
don't
I
don't
want
to.
You
should
have
recognized
that
I'm
making
assumptions
here,
but
in
my
past
experiences
it
doesn't
seem
like
they're.
I
A
F
Open
census
service
be
part
of
this
new
project
and
the
open
census,
collector
and
agent.
You
know
that
all
that
taxi
beverage
stuff
dude
what
be
in
the
fridge
release
mean
it
will
all
still
exist
right,
but
will
it
become
part
of
the
new
thing?
Like
hey
here's,
this
open
sensor
service?
You
should
run
locally
for
collecting
your
traces
and
metrics
I
I.
A
I
Can
provide
a
sort
of
a
semi
answer
to
I
can
address
that
in
some
way.
That's
helpful,
I
mean
I.
Think
the
general
feeling
was
that
there's
some
kind
of
matrix
of
languages
and
different
layers
of
standardization,
around
API
implementations,
and
then
things
like
you
know
that
sidecar
and
everything
and
I
guess
the
sidecar
doesn't
fit
into
a
particular
language.
I
So
much
but
the
the
idea,
if
I
understand
it,
is
to
have
the
merge
project,
be
less
of
a
giant
all-in-one,
take
it
or
leave
it
framework
and
more
as
an
assemblage
of
components
that
are
designed
to
fit
well
with
each
other,
and
so
in
that
sense,
I
think
something
like
that.
Sidecar
project
would
absolutely
be
compatible
with
the
vision
for
the
merged
project,
but
it
wouldn't
be
something
where
you
can
only
use
this
merge
project
to
use
the
sidecar.
I
F
I
Yeah,
correct
yeah
and
even
a
coupling
between
the
API
and
implementation
I
think
it
will
be
the
open
sort
of
the
open
sense
of
style
in
process.
Sdk
agent
would
be
considered.
You
know
the
reference
implementation
and
probably
the
best
thing
for
most
production
use
cases,
but
it
wouldn't
be
by
any
means
required.
I
think
that
okay.