►
From YouTube: Open Tracing Monthly Call - 2018-12-07
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
A
A
B
Okay,
so,
basically
summarize
our
findings
by
implementing
the
first
version
of
the
scope
manager
in
dated
okay
p.m.
actually
mm-hmm
so
yeah
at
first,
it
was
I
think
in
July
that
we
released
the
first
version
of
the
scope
manager.
What
I
did
is
I
implemented
it
exactly
according
to
the
specification
from
open
tracing,
and
while
it's
working
this,
it's
also
led
to
a
few
problems.
For
example,
it
doesn't
really
work
well
with
a
sink
of
weight,
because
the
way
the
construct
is
built,
it
should
be
wrapped
in
a
function
to
work
efficiently.
B
B
I
guess
this
issue
was
mostly
because
we
were
trying
to
keep
track
of
the
guessing
fitness
context,
but
all
children.
So,
for
example,
if
you
schedule
work,
it
would
wait
until
all
the
work
that
you
scheduled
is
finished
to
actually
close
the
scope.
So
a
few
things
there
that
did
not
work
super
efficiently
and
then
there
was
a
PR
and
also
an
issue
opened
by
Paul,
Draper
I.
B
Don't
know
if
he's
I,
don't
think
so,
so
it
was
basically
a
discussion
about
using
continuation
passing
style
instead
of
the
imperative
API
from
the
specification
and
from
there
we
had
a
few
discussions
and
I
think
it
really
makes
sense
to
have
a
continuation
passing
style
for
JavaScript,
and
then
it
led
to
basically
exploring
the
options
for
such
an
API
and
I
think.
In
the
end,
it
deviates
quite
a
bit
from
the
spec
we're
trying
to
keep
the
wording
as
much
as
possible.
B
For
example,
words
like
that
activate,
but
yeah
I
think
for
JavaScript
we'll
need
to
deviate
quite
a
bit.
I,
don't
know
if
you
took
take
a
look
at
the
they
proposed
dpi
but
yeah.
So
that's
that's.
Basically
what
we're
proposing
right
now
and
there's
also
the
issue
that
in
JavaScript
there
are
tons
of
different
runtimes,
for
example,
different
node
versions
that
have
different
restrictions.
Different
capabilities
same
for
the
browser,
which
is
completely
different
than
nodes
and
I,
has
no
construct
at
all.
B
For
context
propagation,
so
there
are
quite
a
few
different
libraries,
depending
on
the
environment
you're
on
to
address
context
predation.
So
the
thing
is
for
the
scope
manager
to
be
compatible
with
node,
zero
point,
ten
plus
and
the
browser
it
needs
to
have
multiple
scope
managers
implemented,
basically
for
all
these
different
runtimes,
great,
so
I
guess
this
is
the
current
state.
Basically.
A
Awesome
yeah.
So
to
summary,
there
is
a
need
for
scope
managers
in
JavaScript
due
to
the
various
runtimes
and
environments
your
code
might
run
in.
So
there
is
a
need
still
for
there
to
be
an
abstracted
scope,
manager
interface,
because
you
do
want
multiple
implementations
and
a
new
API
that
is
more.
Continuation
based
has
been
proposed.
A
B
Yes
and
no
I
mean
the
API
is
very
similar
to
existing
libraries
that
deal
with
context
propagation
but
from
an
application
perspective,
so
arbitrary
values
that
you
want
propagated
and
they
use
a
very
similar
API.
And
if
you
look
at
all
of
them,
even
though
there
are
differences,
it's
basically
the
same
functionalities
that
always
come
back.
So
things
like
well
the
continuation
itself.
B
So
the
ability
to
pass
a
callback
and
have
a
context
and
there
a
few
utilities
for
binding,
because
sometimes
you
want
to
actually
bind
to
a
specific
value
from
a
different
context,
for
example,
and
things
like
that.
But
so
of
course
this
is
at
Oracle
API
at
this
point,
but
it's
based
on
existing
work.
Basically
great.
A
C
D
B
Well,
I
mean
I
think
as
long
as
we
are
still
able
to
support
older
versions,
it
makes
sense
so
that
we
don't
block
anybody.
For
example,
if
some
company
implements
the
open
tracing
JavaScript
for
new
library,
but
they
need
to
support
0.12,
for
example,
it
should
be
possible
if
it's,
you
know
not
too
much
work
to
support,
but
the
thing
is
even
older
versions
of
node
are
not
that
difficult
to
support.
Most
of
the
work
has
already
been
done.
B
The
biggest
part
of
the
work
is
really
to
split
the
current
project
in
multiple
libraries,
so,
for
example,
to
have
each
scope
manager
in
different
modules,
basically
so
that
we
don't
just
bundle
everything,
even
if
it's
not
needed,
and
so
that
that's
pretty
much
the
largest
part
of
the
work-
and
it
has
to
be
done
anyway
to
have
at
the
very
least
one
scope
manager
for
the
browser
and
what
one
scope
manager
for
node.
So
at
that
point,
the
overhead
of
supporting
older
versions
is
not
very
high.
B
C
B
B
But
yeah
I
mean
it's:
it's
also
related
to
the
dependencies.
I
guess
and
open
tracing
JavaScript
doesn't
really
have
a
dependence
a
lot
of
deep
well,
it
doesn't
have
any
dependencies
right
now,
meaning
there
are
basically
two
two
parts
to
this.
In
my
opinion,
so
there's
the
tooling
so
that
like
to
build
to
test
and
that
kind
of
things
where
you
might
want
a
specific
node
support
and
there's
the
actual
output.
B
So
what
you're
gonna
ship,
which
in
this
case
has
no
dependency,
meaning
I,
think
it
would
be
possible
to
update
the
tooling
and
say
okay
to
to
develop
in
the
library.
You
would
need,
for
example,
node
six
and
up,
but
then
still
make
sure
that
the
the
output
would
support
older
version
of.
Of
course,
this
might
be
if
your
tester
doesn't
support
it,
but
I,
don't
know
I'm
just
being
kind
of
devil's
advocate
here,
but
yeah.
B
Right
now,
it's
not
used
anywhere
I
just
forget
to
try
and
make
it
consistent
with
the
other
libraries
I
understand
that
as
English
nurse,
basically
the
first
one,
but
all
future
work
used
a
different,
a
different
way
to
bind
promises
which
is
which
are
always
bound.
When
then,
is
called
and
not
when
resolve
is
called,
which
is
a
major
difference
from
a
sink
listener
which
binds
on
resolve
so
to
have
a
consistent
behavior
between
all
the
implementation
of
a
scope
manager.
B
They
need
to
behave
the
same
for
promises,
so
what
I
did
is
simply
remove
all
the
logic
related
to
the
promise
and
bind
on
then
instead
and
the
idea
was
really
to
have
a
consistent
behavior.
This
is
not
a
problem
with,
for
example,
any
CLS
like
continuation,
local
storage
itself
or
CLS
hooked
and
other
implementations
of
the
sort,
because
you're,
usually
using
only
one
anyway.
So
if
in
your
app,
you
have
note
8
you're
using
ethic
books
and
you
don't
need
to
know
about
I,
think
listener
and
so
on.
B
But
if
you
want
to
have
account
like
a
common
project
like
a
scope,
manager
or
something
of
the
sort,
then
it
becomes
very
important
that
the
scope
is
propagated
exactly
the
same
in
all
implementation.
So-
and
this
is
true
for
also
zone
zone
GS,
which
binds
on
then
no
domains
which
binds
which
bind
on
then
so
pretty
much
the
whole
landscape
at
this
point
binds
and
then
but
I
guess
for
historical
reason.
It's
not
the
case
with
a
sync
listener.
Basically,.
C
We
had
had,
we
have
had
the
discussion
in
the
async
listener.
Repository
I
right
now
can
remember
exactly
why
we
are
still
binding
on
with
resolve
and
not
then
but
I
guess.
It
should
be
possible
to
make
a
new
version.
We
could
even
just
pump
the
major
of
it
that
changes
that
havior,
if
I,
do
not
recall
correctly
I
think
that
should
be
possible.
B
D
B
Is
that
yes,
I'm
exploring
I'm
still
exploring
the
options
because
I
guess
there's
I,
don't
know
what
like
that
people
wants
the
library
to
be
typescript,
so
I'm
I'll
try
to
get
it
to
stay
in
typescript,
but
the
core
library
won't
change,
that's
for
sure,
but
I
mean
because
the
scope,
scope,
manager
itself.
B
The
problem
is
that
they
are
fewer
constructs
like
generators
and
a
sink
awaits
which
are
not
available
in
the
current
targets
version
of
ACMA
script,
so
meaning
that
even
if
you
write
tests
for
a
sink
awaits,
they
will
end
up
as
promises
or
callbacks
or
whatever
works
best
for
the
target.
So
you're
not
actually
testing.
I,
think
await
at
this
point,
and
since
this
is
implemented
in
C++,
it's
not
really
possible
to
replicate
exactly
how
it
works
in
JavaScript
anyway,
so
it
just.
It
will
just
convert
it
to
a
regular
promise
in
the
real
world.
B
It's
fine!
It
will
work
exactly
like
a
secure
wait,
but
when
your
instrumenting
it's
a
bit
different
busy
because
then
yeah,
because
now
you
need
to
really
handle
this
specific
case
and
you
need
it
to
not
be
trans
filed.
Basically.
So
this
is
but
I'm
still
exploring
I'm
still
trying
to
get
it
to
work
and
keep
it
as
typescript.
B
What
I
think
I'll
do
is
use
a
different
target
when
testing,
basically
so
I
won't
pre-compile
to
JavaScript
I
will
just
load
it
directly
with
TS
know
there
something
like
that
to
so
that
it's
it's
compiled
in
memory
and
then
use
a
different
target
and
just
say
like
es
NEX
or
something
like
that,
like
Dolly
the
to
make
the
transformation
as
lightweight
as
possible.
So
yeah.
That's
that's
the
plan
right
now
and
we'll
see
how
this
goes.
E
F
B
Actually,
I
started
this
work
this
week.
It's
not
I
haven't
pushed
anything
yet
the
reason
being
that
I'm
kind
of
realizing
that
this
is
a
bit
of
a
kind
of
worms,
because
I'm
now
that
I'm
also
splitting
the
library
I
need
to
you
know
have
learn,
are
working
with
different
libraries
to
hold
coverage
right
now
as
being
a
bit
of
an
issue,
so
yeah
I'm
I'm
actually
open
to
suggestions
about
how
to
go
about.
B
Let's
say
at
first
like
a
first
push
should
I
just
maybe
not
go
with
the
split
right
away
or
try
just
do
the
split
and
not
the
scope.
Manager
I
mean
I'm,
just
trying
to
basically
figure
out
the
minimum.
That
I
can
do
that.
I
can
actually
push
in
it.
It
works
basically
because,
right
now,
it's
not
really
working.
So
even
if
I
push
it
like
everything's
gonna
just
fail
and
which
I
could
do
as
well.
If
you
want
to
take
a
look
but
yeah
I'm,
open.
C
To
suggest
it's,
it's
it's
fine!
You
if
you
ever
need
more
time
to
figure
out
how
how
it's
best
are.
Then,
then
that's
fine
I
was
just
thinking
like.
If
you
wanted
a
feedback,
it
would
be
easier
if
it
was
I,
don't
know,
maybe
I'm
not
really
possible
to
do
in
a
PR
or
or
in
a
separate
fork,
or
something
that,
of
course,
you
shouldn't
push
it
to
necessarily
master
but
yeah.
It
was
just
to
see
if
I
could
get
a
give
any
feedback
at
this
point,
then
it
would
easier,
but
it.
B
Yeah
my
plan
was
actually
to
like
either
make
a
PR
or
at
least
push
something
next
week,
probably
by
the
middle
of
the
week,
if
if
possible,
and
then
we
can
discuss
any
anything
that
is
from
from
the
points
that
we
mentioned
and
yeah
that's
so
that's
the
plan.
I'll
try
to
push
something
the
next
few
days,
basically
great.
A
A
I
had
a
couple
questions
on
that
front.
One
was
just
to
circle
back
to
node,
virgin
support
and
just
to
clarify.
Is
there
anything
about?
Besides,
just
you
know,
tooling,
in
dependency
management?
Is
there
anything
about
the
API
being
proposed
that
people
would
change
if
we
changed
what
kind
of
node
support
we
were
looking
at,
which
is
purely
a
tooling
question.
A
B
Not
that
I
know
of
I
think
and
I'm
not
sure
about
this,
because
it's
been
supported
for
a
long
time,
but
I
think
one
of
the
reasons
may
be
that
everything
is
a
function
as
opposed
to
getters
in
some
cases
is
because
it
may
have
not
been
supported
in
those
versions
but
I'm,
not
100%
sure,
but
I.
Didn't
that
in
at
least
my
point
of
view,
I
think
the
API
is
would
be
exactly
the
same.
Then
you
were
load
version
great.
A
Thanks
for
clarifying
I
had
some
questions
just
about
the
API
itself.
In
particular,
I
was
curious
about
the
usage
of
being
able
to
access
the
Scopes
parent
scope
and
route
scope.
That's
probably
the
biggest
change
I
noticed
from
a
functionality
standpoint
compared
to
other
scope,
managers
and
I
was
curious
about
the
intention
behind
exposing
exposing
the
scope
chain
in
that
manner.
Oh.
B
So
I
really
don't
have
a
clear
idea
of
how
this
this
would
work,
but
the
idea
is
that
in
some
cases
you
may
want
to
enrich-
maybe
the
parent-
or
in
our
case
what
happens
a
lot
more
often
is
to
enrich
the
route
and
right
now
there's
no
way
to
to
get
the
roots,
basically
so
I'm
more
concerned
about
the
roots
than
the
parent,
to
be
honest
and
in
most
of
our
tracers,
who
started
to
basically
add
this
concept
of
route.
B
I
think
it's
called
something
like
active
route
span
or
something
like
that,
which
is
a
property
that
we're
slowly
adding
to
the
tracers.
The
problem
for
me
is
that
I'm
trying
to
keep
the
JavaScript
implementation
as
a
hundred
percent
open
tracing,
meaning,
if
possible,
and
so
far
it's
been
possible.
I,
don't
add
anything
that
is
not
open
like
fully
open
tracing
compliant,
meaning
that,
if
you
put
the
tracer
as
a
global
open
tracing,
it
will
you're,
not
ok,
so
right
now
the
problem
becomes.
How
do
I
add
this
active
route
span
so
far?
B
I
didn't
really
need
it
for
anything
in
note,
but
it's
starting,
you
know
to
show
that
I
might
mean
that's
pretty
soon
and
I
I
I
think
the
best
place
to
have
that
is
under
scope
manager
because
then
well,
I'm
not
actually
sure,
because
it
can
also
be
under
span
right.
So
the
span
knows
it's
parents,
because
for
the
scope
I
mean
this
the
the
kind
of
the
tree
of
all
the
all
the
Scopes.
B
It's
not
really
the
same
as
necessarily
for
a
span,
so
your
parent
scope
may
not
contain
your
parents
pan
or
something
like
that.
So
I'm,
actually
not
a
hundred
percent
sure.
This
may
be
another
discussion
completely
and
and
end
up
being
unrelated
to
the
scope
manager
but
yeah
it's
it's
really.
The
need
is
basically
to
be
able
to
grab
the
roots
span.
Actually.
A
So-
and
this
is
related
to
a
sort
of
best
practice
that
you're
trying
to
develop
a
data
dog
around
instrumentation,
you
mentioned
decorating
the
root
span
that
there's
cases
where
you
want
to
be
adding
information
at
some
roots
fan
as
opposed
to
local
roots
fan.
I,
guess
I
should
say
right:
it's
not
the
root
of
the
trace.
Necessarily,
oh
yes,.
B
Because
the
way,
the
way
it's
we
actually
do,
it
is
well,
of
course,
we
have
spans
and
all
these
spans
are
part
of
a
trace,
so
that
would
be
your
local
trace
and
then
each
of
those
local
traces
are
combined
together
into
like
a
distributed
trace
like
a
real,
a
real
trace
of
your
entire
system.
So
in
some
cases
we
have,
since
we
have
these
like
strong
concepts
of
traces.
B
C
A
Yeah
I,
don't
think
it's
a
crazy
concept,
but
I
am
noting
it
that
there's
been
aspects
yeah
where
the
open
tracing
API
currently
doesn't
provide
accesses
root
span
around
that
or
some
concept
of
like
this
is
the
the
processor
service.
The
span
is
running
in
or
some
way
of
conceptualizing
that,
like
information,
that's
a
place
where,
at
light
step,
for
example,
we
tend
to
have
some
attributes.
We
call
them,
but
basically
tags
that
are
on
every
span
that
comes
through
a
service
or
a
kind
of
concept
like
that
and
I.
A
Imagine
other
people
up
something
similar,
so
I'm
only
bringing
it
up,
because
this
is
surfacing,
as
you
know,
a
feature
in
the
JavaScript
API,
but
it
may
be.
I
always
want
to
put
a
pin.
If
we're
seeing
one
API
diverge
to
ask.
Is
this
really
a
JavaScript
specific
issue,
or
is
this
like
a
general
issue
and
we
just
are
encountering
it
at
JavaScript?
For
the
first
time
we.
A
So
I
think
my
only
suggestion
there
would
be
like
I
like
this
API,
and
it
looks
good
I
wonder
if
we
could
separate
out
here
is
like
a
good
continuation
based
implementation
of
the
scope
manager.
Api
here
is
like
an
additional
concept.
We
want
to
add
to
the
open
tracing
specification
around.
You
know,
root
access
or
you
know,
root,
scope,
access
or
something
like
that.
Maybe
make
them
slightly
separate
issues.
A
B
E
I
also
was
thinking,
and
this
isn't
for
right
now,
but
once
this
is
a
little
bit
further
along
well.
First
of
all,
I've
been
quiet,
for
this
sounds
like
really
frankly,
really
excited
about
this
work.
I
think
it's
great
to
have
pending
JavaScript
such
a
weird
language.
That
time
we
know
it's
going
to
demand
something
that
isn't
then
white
like
flips
in
Java,
or
you
know
whatever
so
I'm
glad
that
we're
having
specially
now
before
it's
too
late
and
I'm
excited
about
it.
E
It
might
be
useful
once
we
get
a
little
further
ahead
to
kind
of
mark
the
parts
of
the
API
that
we
actually
aren't
touching
the
like
the
important
parts
of
the
API
that
we
are
touching
and
like
certain
kind
of
data
model
type
things
stuff
like
that,
just
so
that
people
who
go
bound
to
what
we
have
now
will
have
less
anxiety
about
this
landing.
I
think
it's
inevitable
that
we
do
something:
that's
a
breaking
change
in
some
way
to
the
JavaScript
of
entry.
E
Some
JavaScript
that's
fine,
fine,
but
if
we
can
try
to
cordon
off
parts
that
are
actually
safe,
that
might
be
useful
for
people
as
the
release
candidate
gets
closer
to
landings.
Keeping
keeping
that
in
mind,
because
I
actually
think
that
that
most
people
will
probably
be
pretty
happy
about
the
upgrade
to
this,
but
it'll
be
helpful
to
ease
anxiety.
It's
just
prior
experience
of
increasing
like
every
time.
You've
made
a
breaking
change.
It's
been
for
a
good
reason,
but
naturally
people
kind
of
freak
out
about
it.
E
Think
we
should
just
you
know,
there's
maybe
there's
no
action
right
now,
it's
more
a
general
request
based
on
prior
experience
to
to
try
and
I
think
the
part
of
this
change
that
will
actually
affect
people
by
explaining
what
won't
affect
people
like
people
have
mainly
been
like
adding
tags
and
spans
and
stuff
like
that,
like
that's,
probably
not
going
to
be
very
much
different
at
all.
It's
like
for
day-in,
day-out
use
cases.
E
The
API
probably
won't
affect
things
it's
mostly
when
you're
actually
integrating
with
frameworks,
and
things
like
that,
where
you
have
to
think
more
about
control
flow,
that
these
sorts
of
changes
will
be
more
disruptive,
but
if
someone's
taking
currently
I
had
to
spin
adding
some
tags
to
it
and
then
moving
on,
like
that's
not
going
to
feel
I
assume.
That
won't
be
that
much
different
after
this
changes
got
through
this
I.
A
Think
one
action
is
just
as
we
are
rolling
with
the
release
candidate.
Here
we
want
to
look
at.
How
is
this
a
breaking
change?
How
what
is
the
upgrade
path
and
be
explicit
about
the
upgrade
path
for
existing
code
and
in
the
past
and
Java,
for
example,
we've
sometimes
written
shims
or
helper
modules
that
smooth
over
some
of
that
transition.
E
E
This
is
for
garden-variety
code.
It's
not
really
going
to
change
like
don't
worry
so
much
I'll
write
these
shims
and
kind
of
move
on
and
and
I'm
just
trying
to
figure
out
like
how
many
avoid
a
situation
with
this
set
of
changes.
How
can
we
make
it
so
that
you
know
if
there
are
a
bunch
of
people
who
really
understand
this
stuff?
Well,
they
feel
good
about
it.
E
B
Would
say
it's
not
like
I,
don't
think
there
is
a
breaking
change
if
I'm
not
mistaken,
so
it
should
be
pretty
smooth
since
there
isn't
no
breaking
change
the
only
kind
of
breaking
change,
but
it's
not
really
breaking.
Is
that
once
you
start
using
a
scope
manager
and
the
reason
it's
not
breaking
it's,
because
it's
optional,
so
by
default
you
get
a
no
up,
so
it
doesn't
doesn't
matter.
But
as
soon
as
you
put
the
scope
manager
in
what
is
gonna
happen,
and
that's
that's
from
the
specification.
B
B
E
E
A
change!
It's
like
a
it's,
a
change
of
behavior
that
you
get
by
upgrading
your
API,
but
you're
right.
It's
not
a
breaking
change.
It's
probably
less
likely
for
many
reasons
that
this
will
cause
a
lot
of
anxiety,
so
hopefully
I'm
just
a
little
bit
traumatized
after
the
Java
experience
and
that
won't
be
relevant
here,
but
that
yeah
that's
a
really
good
point.
Thank
you.
I
think.
A
The
only
call
out
there
is
yet,
let's
make
sure
if
we
have
some
stuff,
that's
experimental.
It
also
looks
additive,
and
so
it
would
probably
be
good
to
have
a
release
of
the
scope
manager
that
only
contained
you
know
the
parts
that
we
think
are
necessary
and
well-thought-out
and
then
have
a
you
know.
Ii.
You
know
follow-up
release
that
maybe
adds
routines
or
some
other
concept
like
that
and
make
sure
if
it's
just
additive
changes
we're
thinking
separated
into
two
releases.
So
we
have
time
to
get
it
right.
F
B
You
also
remove
things
like
the
bind,
and
things
like
that
I
mean
these
are
are
very
useful,
but
they
can
be
done
outside
of
the
library
pretty
easily
as
well.
It's
just.
It
was
just
to
avoid
that
everyone
has,
to
you,
know,
repeat
this
code,
because
it's
got
it's
kind
of
involved.
It's
not
a
lot
of
lines
of
code,
but
it's
like
you.
You
have
to
know
what
you're
doing
to
to
write
it.
Basically
I
thought.
A
That
code
seemed
fine
that
just
seemed
like
convenience
that
we
were
adding,
though
I
will
say
we
have
occasionally
added
some
sugar
and
then
paid
for
it
later.
So
maybe
we
should
you
know,
review
sugar
or
anything.
That's
in
there
that's
convenient,
but
certainly
code
that
everyone
will
have
to
write,
but
is
slightly
tricky
and
really
there's
only
one
good
way
to
write
it.
That
sounds
precisely
like
the
thing
that
should
be
in
the
API.
A
The
only
thing
for
me
were
things
that
were
semantic
differences,
especially
if
there
are
things
that
maybe
put
pressure
on
the
tracer
to
have
to
now
keep
track
of
things
or
somehow
influence
your
tracer
implementation.
Those
are
the
parts
where
we
want
to
make
sure
we're
doing.
Just
we've
done
enough
experimentation,
and
you
know
put
that
those
concepts
in
their
paces
before
releasing
them.
That's
all
and
I
wouldn't
want
to
hold
up
this
other
work.
C
Could
say
that
that
we
have
a
scope
manager
already,
of
course,
in
arresting
a
PM
that
we
made
ourselves
and
that
uses
those
to
bind,
or
it
has
a
similar
content
that
those
to
find
find
things,
because
it's
essential
and
note
rjs
to
be
able
to
do
that.
This
is
a
very
node
G,
a
specific
thing
of
course.
Yes,
oh.
B
B
C
B
Okay,
the
I
mean
I
totally
agree
and,
of
course,
we
know
that
this
is
also
true
for
any
integrations.
So
any
automatic
instrumentation,
for
example,
but
also
I,
mean
I,
would
say,
you're
basically
distributing
the
nightmare,
basically
by
not
putting
it
in
the
inter
library
itself,
because
then,
because
for
sure
it's
something
everyone
will
have
to
do
right,
because
if
you
don't
patch
Bluebird,
you
lose
your
context.
B
So
it's
simple
as
that,
and
even
if
you're
not
using
Bluebird,
there
are
a
very
high
chance
you're
using
a
library,
that's
using
Bluebird
and
at
the
end
of
the
day,
you're
using.
So
the
problem
is
basically
that
everyone
will
have
to
implement
this,
and
everyone
will
have
the
same
nightmare,
but
at
the
same
time
they
won't
collaborate
together
to
to
address
that.
B
The
advantage
would
be
that
if
there's
something
needs
to
be
fixed
or
some
new
library
needs
to
be
to
be
addressed,
then
it
can
all
be
done
in
there
I
mean,
of
course,
it
could
not
be
in
the
core
repository,
maybe
but
I
think
it
would
benefit
everyone
to
have
it
there.
Of
course,
we
would
need
to
have
a
lot
of
safeguards
to
make
sure
that,
for
example,
if
Bluebird
five
point
X
is
released
and
it's
different,
it
works
differently
or
something
like
that.
I
mean
I.
Think
it's
fine.
B
If
a
new
version
is
released
and
it's
not
working
meaning
you
lose.
What
is
not
fine,
if
is
if
it
breaks,
so,
the
only
concern
I
would
have
is
to
say
it
needs
to
be
super
safe.
So
as
soon
as
anything
fails,
it
should
just
continue
execution
right,
not
true
or
anything
but
yeah.
This
is
my.
This
is
my
take
on
yeah.
C
I
I
agree
also
with
that,
so
there
you
can
see
kind
of
see
from
from
two
angles
right,
so
so
yeah
I
think
maybe
it
would
be
really
really
good
if
this
could
actually
kind
of
live.
I,
don't
know
if
it's
possible,
but
if
this
could
live
as
a
separate
project
that
is
not
a
really
tied
to
open
tracing,
so
even
non
open
tracing
traces
could
also
make
use
of
this,
and,
and
that
would
that
would
mean,
hopefully
that
we
get
even
more
eyes
on
it.
I
don't
know
this
is
possible.
C
This
is
possible,
but
if
you
could
make
the
API
in
a
way,
so
it's
not
so
it
doesn't
expect
open
tracing
to
be
there.
That
would
be.
That
would
be
the
best
scenario
growing
going
forward.
Obviously,
the
right
solution
to
this
is
to
catch
all
the
libraries
that
have
this
user
line
callback
queue.
This
is,
this
is
a
project
that
we
kind
of
had
worked
on
and
the
node
foundation,
because
with
agent
hooks,
there
is
a
providers
API
that
actually,
these
libraries
are
supposed
to
use
if
they
want
to
not
lose
context.
C
And
so
we
have
opened
a
few
PRS
and
these
libraries
to
see
if
we
can
make
them
users
API
and
if
week
and
and
this
problem
will
result
by
the
library
itself,
instead
of
we
having
to
to
monkey
patch
things,
which
of
course
is
the
right
solution,
but
that
only
works
for
nodes,
8.1
and
above
obviously,
because
Asian
crooks
needs
to
be.
There.
B
Yes,
and
also
you
need
for
sure,
you
need
the
support
of
of
that
libraries
team,
basically
to
be
able
to
to
be
able
to
do
that.
I
I
think
most
of
them
are
promised
libraries
anyway.
I
haven't
really
seen
any
other
library
word.
This
is
where
the
context
is
really
lost,
or
at
least
not
a
very
commonly
used.
One
PG.
C
Postgres,
basically,
every
database
driver
on
the
planet
will
probably
that
at
least
one
that
uses
TCP
will
probably
have
a
socket
pool
and
that
socket
pool
will
have
this
problem.
They
most
of
them
use
this
module
called
generic
rule
that
they
share
and
generic
will
have
this
problem.
So
if
you
patched
generic
rule,
you
will
you
will
fix
it
for
most
database
drivers.
What
is
a
big
portion
of
them,
but
that
has
the
same
problem.
A
A
Read
me
that
includes
all
this
good
stuff,
yeah
but
I
think
that's
where
this
conversation
should
continue
and
I
hope
to
see
everybody
there
and
I'm
looking
forward
to
your
PR,
Rach
cool.
So
just
final,
a
couple
minutes
other
orders
of
business
Austin
you're
asking
about
some
ownership
for
some
tool
chains.
D
F
G
G
F
G
C
A
E
We've
done
things
in
the
past,
but
I
don't
feel
strongly
about
this
at
all,
but
you
know
like
created,
like
a
distribution
list
on
like
an
email
address.
Do
that
then
sends
off
to
various
people
who
care
just
to
you
know
multiplex
it,
but
I
don't
feel
strongly
about
it.
Yeah,
of
course,
that
path
that
ends
up
being
a
skills
and
key
for
password,
resets
and
stuff.
So
you
have
to
be
careful
about
it.
I
don't
feel
strongly
about
how
we
do
it
I'm
happy
to
do
that
again.
If
it's
helpful.
A
A
H
You
know
familiar
with
open,
releasing
Java
today,
but
there's
a
pending
will
request
that
I
would
like
to
get
moving
if
possible,
for
you
know
prior
to
do
a
second
release
candidate
essentially
well,
if
the
link
is
in
the
document
and
it's
about
the
possibility
of
activating
ice-pan
context
inst,
you
know
in
addition
to
a
span-
and
this
is
when
you
don't
have
any
control
over
the
lifetime
of
a
span,
and
you
don't
want
to
have
you
know
like
you
do
want
to
end
up
in
the
situation
where
you
are
passing
an
activist
panelling.
H
It
gets
activated,
but
it's
already
finished
and
then
you
are
trying
to
set
tax
or
stop
or
overly
on
it,
and
so
it's
not
working
and
it's
kind
of
I
think
it's
very,
very
personal
opinion.
I
think
it
could
be
something
nice
to
have
it's
kind
of
a
slightly
polemical.
Actually.
So,
if
there's
anybody
here
familiar
just
like
I
would
love
to
get
any
feedback
on
that
I
think
it's
something!
H
It
would
be
nice
a
nice
addition,
but
it's
actually
the
one
of
the
problems,
probably
that
it
could
be
adding
some
complexity
to
the
API,
because
then
there's
a
current
invariant,
where,
if
you
have
a
scope,
you
always
have
a
ice-pan,
but
then
these
could
be
breaking
that
so
yeah.
If
anybody
has
any
kind
of
feedback
or
even
if
you
are
even
if
you
guys
are
not
familiar
with
the
open
trace
in
July
API
use,
let
us
know
I
think
we
would
always
be
be
happy
to
get
some
feedback
for
that.
I.
A
A
A
A
A
I
don't
know
if
there's
people
on
this
call
who
also
work
with
census,
the
census
team
on
the
JavaScript
side,
but
given
the
way
things
are
going,
yeah
I
do
think
it's
totally
reasonable
to
check
in
with
them
and
kind
of
see
that
we're
all
sort
of
growing
the
same
direction
on
some
of
these
concepts
or,
if
we're
not
like.
Why
not
is
there
like
a
good
reason
like?
Are
there
API
decisions
getting
made
that
we
can
learn
from
over
there,
but
I
don't
work
personally
with
it.