►
From YouTube: 2020-10-21 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
C
D
Well,
I
don't
ordinarily
attend
this
and
I
apologize
for
that.
I
see
now
that
I
should
find
the
notes
document
from
this
morning.
D
I
know
I
in
particular
called
for
some
of
this
meeting
to
happen
or
invited
people
to
discuss
this
topic
on
the
agenda
here
about
span
context,
and
I
have
to
confess
I
don't
have
a
specific
agenda.
Let
me
project
this
screen
other
than
to
clarify
what
we're
going
to
do
as
a
member
of
tc.
I
am
assigned
these
issues.
Some
of
them
are
mine
and,
as
a
you
know,
member
of
the
community,
I'm
interested
in
the
outcome
so
anarag,
I
noticed
you
have
filed
a
number
of
issues.
There
are
also
some
back
background
issues.
D
One
one
was
fought
by
yuri
one
was
written
by
me
to
me.
These
all
explore
the
same
question.
It's
not
an
easy
one.
I'd
like
to
have
others
speak
though,
so
honorable
could
you
to
me
I'd
like
you
to
tell
me
where
you
think
we
should
be
where
you
think
we
can
be.
I
said
this
morning.
I
don't
think
it's
wise
for
us
to
change
names
to
try
and
kick
expand
context
away
from
the
specification,
although
it
is
really
causing
some
confusion.
D
So
maybe
we
should
let
me
hand
it
over
to
you.
B
Yes,
I
think
I
would
say,
while
implementing
some
of
the
changes,
for
example,
especially
christian,
implemented
the
change
to
parent
everything
from
context
writing
code.
It
just
felt
like
we're
not
using
this
banned
context
anymore.
It's
just
a
holder
of
ids
and
I
thought
things
could
get
simplified
if
it
just
went
away
like,
for
example,
even
propagation.
B
D
F
It
I
will
say
I
think,
we're
if
we're
going
to
expose
this
concept,
as
is,
we
should
probably
keep
the
name
span
context
just
because
it's
gonna
throw
so
many
people
for
a
loop,
but
I
do
like
your
idea
of
potentially
just
hiding
this
thing
entirely.
F
If
it's
not
necessary
to
expose
this
at
all
to
people,
that
would
be
a
win.
D
Tristan,
I
know
you
said
something
this
morning
about
having
an
opinion
opinion
here.
G
Well,
yeah,
I
mean
my
first
note
was
simply:
I
had
no
idea
that
span
context
in
the
context
of
open
tracing
had
so
much
more
to
it
than
just
you
know,
spam
id
trace
id
and
open
census.
That's
all
it
was,
and
so
we
in
the
early
lecture
implementation
have
to
have
a
a
span
reference
of
some
sort,
so
we
had
just
been
naming.
We
had
just
named
it
spam
context,
but
not
really
tied
to
that,
except
for
that's
how
everybody's
been
discussing
it
for
months
now.
G
Signifies
what
it
is
better
and
just
having
a
span
for
everything
else,
even
if
well
yeah
I
mean
we
would
use
a
span
reference,
a
lot
of
places
where
everybody
else
uses
a
span
because
we
store
it
store,
the
actual
span,
attributes
and
everything
in
a
shared
table.
But
I
think
overall,
arena
changing
the
name
to
get
rid
to
not
have
the
duplicate
use
of
context
everywhere
would
be
good,
but
maybe
too
too
late
to
do
it.
G
Yeah,
I
guess
like
for
us,
you
pretty
much
are
in
a
sense
so.
G
F
Is
it
actually
feasible
to
remove
span
context
from
our
public
api
like
where
do
people
off
the
top
of
their
heads
have?
Can
people
bring
up
examples
where
they
know
it's
still
necessary.
B
F
So
traditionally
the
reason
we
kept
it
around
was
because
you
would
have
situation
where
you
would
ex.
You
would
have
this
information
because
you
have
extracted
it,
but
you
have
not
created
a
span
yet
so
that
was
why
and
but
yeah
like
you're
saying
we're
not
doing
that
anymore,
so
it
just
seems
like
it
could
just
evaporate.
At
this
point.
G
F
F
A
There's
one
there's
one
other
place
which,
with
the
change
that
the
samplers
get
the
context,
if
you
want
to
ask
about
things
like
whether
whether
the
parent
span
was
sampled,
I
think
it's
sampled.
You
have
to
get
that
out
of
this
van
context,
which
you
get
out
of
the
span.
A
F
F
From
your
carrier
and
that
stuff
has
to
go
into
something,
if
that
something
is
no
longer
a
span
context,
then
we're
done
that
was
always
the
blocker
was
we
want
to
have
a
way
of
passing
around
a
context
without
creating
a
span,
for
example,
wanting
to
serialize
one
or
hold
it
for
some
reason
or
shovel
it
around
to
to
start
it
somewhere
else.
F
I
feel
like
we're.
Moving
away
from
that
model,
pretty
heavily
in
open
telemetry
and
towards
a
model.
That's
more
like
there
is
a
current
span.
You
should
be
focusing
on
that
thing
and
you
should
be
juggling
lots
of
spam
contacts,
and
things
like
that,
so
you
know
I
I
would
be
down
to
try.
My
only
nervousness
is
that
you
know
when
we,
when
we
dive
at
these
at
the
last
minute,
are
we
going
to
get
well
into
like
starting
to
implement
this
in
a
bunch
of
places
and
then
go
like?
F
Oh,
oh
there's
that
other
edge
case
that
I
didn't
think
about,
because
that
that
happens.
Basically,
every
time
we've
tried
to
be
like.
Why
do
we
need
this
thing?
Let's,
let's
just
like
span
status
right
like
yeah,
we're
like
we
don't
need
it
and
then
a
bunch
of
things
started
to
unravel
and
we're
like.
Oh,
it
would
be
very
bad
if
we
remove
this.
D
And
so
I
I
feel
like
there's
a
question
here
about
and
I
want
to
turn
it.
I
want
to
ask
yuri
to
speak
because
there's
a
question
about
spam
versus
spam
contacts.
Okay
and
this
I
I've
I've
tried
to
write
the
same.
I
think
there's
an
equivalent
question
is:
can
we
remove
spam
context?
Call
yes,
can
we
remove
spam?
D
Probably,
yes,
the
reason
is:
we've
got
this
sort
of
redundant
concept
and
I
think
we
can
decide
which
one
we
want
to
redundant,
but
I,
I
think
we're
all
agreeing
that
there's,
maybe
a
problem
in
having
this
redundancy
and
not
clearly
spelling
it
out.
My
proposal
in
otep
73,
which
says
span
equals
span
context,
is
to
try
and
simplify
the
situation
and
and
here's
the
situation
though.
However,
in
go,
I
work
and
go
most
of
the
time
and
in
go
there's
this
built-in
context
type
the
situation.
D
You
can't
copy
this
into
a
struct,
because
idiomatically
this
thing
called
a
context,
is
supposed
to
be
a
sort
of
transient
stack
state,
not
in
a
struct
state,
and
so
the
problem,
when
you're
working
with
open,
telemetry
and
tracing
apis
in
general,
is
that
you
have
this
thing
called
a
span
which
is
sometimes
in
the
context,
and
sometimes
it's
an
explicit
thing
and
what
I
was
trying
to
all
I'm
trying
to
say
in
otep
73,
which
is
the
one
that
says,
span
equals
and
context.
D
Is
that
holding
a
span
context
well,
sorry,
holding
a
span
is
essentially
equivalent
to
holding
a
to
being
in
a
context
where
that
span
is
active
and
the
concept
of
spam
spam
context
has
been
used
at
times
to
try
and
make
a
distinction
that
I
don't
believe
in
and
once
to
me
it's
not
a
semantic
distinction.
It's
an
operational
one.
It
says
like
there's
a
problem
that
that
some
some
implementations
have
when
you
start
a
span
holding
a
holding
a
parent
contact.
D
Now
you
have
another
child
context
and
you
have
a
span
object
for
that
and
you
you
want
to
kind
of
hold
a.
I
use
the
word
reference.
You
want
to
hold
a
reference
that
span
and
at
some
point
you've
got
some
activities
and
some
asynchronous
activities
you're
going
to
end
that
span
and
now
I'm
going
to
have.
I
want
to
refer
to
that
span
again
because
I'm
going
to
create
an
asynchronous
child
after
the
parents
and
and
that
it
doesn't
make
sense
in
some
sense
to
talk
about
the
span,
because
that's
ban
ended.
D
So
what
I
tried
to
say
in
73
and
I'll
stop
talking
to
sack
is
really
that
a
span
is
essentially
the
materialization
of
a
context
that
I'm
allowed
to
store
and
instruct
because
in
go
I
can't
store
a
context
instruct
idiomatically
speaking.
That's
all.
Is
it
like
to
me
they're
the
same
idea,
and
I
want
to
say
yes,
we
can
get
rid
of
this
man.
Context
put
it
in
span,
but
then
don't
make
it
an
error.
G
H
G
Everything
to
it
and
that,
maybe
you
can
add
to
it,
but
all
you
need
is
those
three
ids
or
three
fields
in
a
lot
of
cases
like
you
could
have
like,
I
think,
of
the
job
queue
or
kafka,
or
something
and
you're,
including
a
bunch
of
headers,
of
all
these
other
spans
that
have
been
linked
to
it
and
you
just
want
trace
id
span
id
trace
date,
and
you
probably,
and
it
just.
A
D
And
this
question
of
propagated
spans
is
kind
of
the
same
one,
because
if
your
problem
is
that
the
link
api
requires
a
context
now,
instead
of
a
span
context,
because
we've
eliminated
span
context,
what
does
the
caller
do?
That
only
has
those
three
identifiers
you
just
named
what
they
do
is
they
create
a
propagated
span,
essentially
mimicking
the
extraction
of
those
identifiers
into
a
context.
They
pass
that
context
as
the
link
and
it
works
as
intended.
D
G
F
F
I
wouldn't
want
something
like
that
leaking
into
the
public
api,
though,
because
I
agree
with
tristan:
that's
that's
like
one
step
forward
and
one
step
back,
but
if
that's
a
thing
that,
from
the
end
user's
point
of
view,
they
only
have
spans
and
if
they're
using
a
span,
that's
that's
already
been
ended
or
a
span.
That's
one
of
these
things
and
they're
calling
methods
on
it
that
are
guaranteed
not
to
work.
At
that
point,
I
think
you
know,
at
least
in
debug
mode.
F
We
can
be
giving
them
warnings
like
you're
calling
this
thing
and
I'm
dropping
it
on
the
floor.
Just
to
let
you
know,
and
that
would
be
pretty
fine
and
I
don't
think
our
end
users
would
necessarily
be
weirded
out
about
the
idea
of
handing
ended
spans
around
like
there's
the
idea
of
like
your
active
span,
that's
running
and
you're
doing
stuff
with
it
and
then
there's.
The
idea
of
you
have
this
span
now
as
an
object
that
you're
kind
of
passing
around
somewhere,
because
because
programming
and
because
reasons.
G
F
Was
the
other
the
other
thing,
but
I
wonder
whether,
like
it
does,
this
is
comes
down
to
how
languages
work,
but
you
could
have
a
certainly
in
go.
It's
easy
enough
to
have
a
small
immutable
struct.
That
only
has
those
three
fields
completely
implement
the
span
interface
right
it
just
it
just
does
it's
just
no
ops,
except
for
the
things
that
let
you,
except
for
the
getters,
the
only
getters
we
have
are
the
span
context.
A
So
the
java,
the
java
implementation
today
basically
works
that
way.
We
have
an
interface
for
the
span
and
you
can
call
rap
with
a
any
given
span
context
and
it
gives
you
back.
It
happens
to
be
implemented
by
a
class
called
propagated
span,
but
it's
not
exposed
to
the
api.
Just
give
you
back
a
span
that
no
ops
in
the
right
places.
F
Yeah
they
get
an
x,
they
can
extract
a
context
you
through
a
public
api.
You
can
never
extract
a
span
or
something
like
that
from
a
carrier
right.
You
can
extract
a
context
from
a
carrier
and
then
the
extractor
under
the
hood
can
be
you
know
extracting
spans
and
other
things
from
that
carrier
and
putting
it
into
the
context.
But
by
the
time
the
end
user
gets
it.
It's
just.
This
context
object
that
they
can
run
open
telemetry
operations
on
there's
no
fiddling
about
with
any
additional
objects.
D
D
I
just
worried
about
saying
I'm
not
supposed
to
store
these
instructs,
but
I
I
can
always
just
work
around
that
like
I
can
have
a
function
that
takes
context
as
an
argument
and
like
I
can
like
I
can
just
make
this
work
and
sometimes
that's
the
way
I
prefer
to
do
it.
But
if
I
want
to
store
a
context,
maybe
I
should
just
call
it
a
span.
However,
it's
a
span
that
I
never
started.
D
So
it's
a
sort
of
partial
span.
How
do
I?
I
don't
have
to
specify
how
that's
created
it's
just
another
kind
of
no
I'm
standing
so
can
we
create?
Can
we
treat
this
thing?
You
extract
as
a
just
another
kind
of
implementation
of
span.
I
think
the
answer
is
maybe,
and
that
might
solve
this
problem.
I
I
I
I
want
to
stop
talking
myself,
maybe
yuri
you
could
comment,
since
you
are
the
author
of
issue
68,
which
is
another
one
of
the
influential
I
think
sort
of
position
pieces
on
this
topic.
H
From
when
I
think
about
the
cleanliness
of
the
api
to
me,
the
separation
of
span
and
span
context
makes
the
most
sense,
because
that
very
clearly
gives
you
api
with
methods
that
you
can
call,
or
you
don't
have
those
methods
to
call
in
the
first
place
right
and
and
that
changes
depends
on
the
context.
So
when
you
extract
something-
and
it
happens
to
be
spam
context,
then
well,
you
cannot
record
any
events
of
it
and
you
shouldn't,
because
that
doesn't
belong
to
you,
that
spanned
from
a
different
process.
H
So
in
order
to
record
something,
you
could
create
a
new
span
and
that's
a
recordable
object
on
which
you
can
call
methods.
So
I
was
not
in
favor
of
propagated
span
because
it
confuses,
I
think,
the
the
issue
by
pretending
to
have
to
be
something
that
it's
not
it's
like
exposing
an
api,
but
at
runtime
that
api
happens
to
be
no
op,
then
well.
Why
does
it
expose
that
api?
H
H
F
F
So
any
concept
we
can
remove
from
the
public
api
makes
it
simplifies
the
mental
model
for
our
end
users.
So
I
mean
whether
this
one
is
like
worth
it
or
not.
I
don't
know
I
mean
it's
obviously
debatable,
but
to
me
I'm
I'm
fine,
removing
public
complexity,
if
even
if
it
creates
more
private
complexity,
maybe
not
if
it
creates
more.
You
know
overhead,
but
you
know
we
we
can
handle
the
complexity
better
than
our
end
users.
Can
I
guess
that's
what
I'm
trying
to
say.
F
But
I
hear
you
about
the
cleanliness
right.
That
was
the
whole
thing
in
open
tracing
of,
like
spans,
have
no
getters
right,
they're,
just
an
interface
and
the
span
context
is
the
thing
that
has
the
getters
and
it's
actually
an
immutable
object,
and
so
it's
clean
cleanly
factored.
But
it's
like
when
you
cleanly
factor
things
enough.
F
You
end
up
with
a
whole
bunch
of
objects
and
if
you're
only
vaguely
familiar
with
this
thing,
because
it's
like
this
ap,
you
know
the
secondary
system
that
you're
using
perhaps
infrequently,
then
all
those
extra
concepts
do
actually
carry
a
load.
F
If
we
can't
do
that,
if
it
creates
some
weird
squiggle
somewhere,
where
some
some
other
ugliness
comes
out,
then
then
I
agree
we
shouldn't,
which
is
always
my
fear,
with
removing
span
entirely
by
the
way
which
is
like
it
seems
like
it
makes
things
simple
in
some
areas,
but
I
get
we've
never
really
proven
that
it
doesn't
make
other
things
nasty
or
impossible.
F
H
Well,
look,
sir.
The
one
challenge
with
removing
span
is
again
this
up
cleanliness
of
the
api,
because,
if
you
don't
have
spam,
that
means
you
have
tracer.
do
something
and
you
pass
a
context
to
it
right,
which
means
that
you
can
also
pass
a
context
that
you
just
extracted,
which
is
not
the
real
context.
You
can
actually
call
those
methods
on
right,
so
it's
it's
kind
of
a
chick
in
the
neck.
Here
you
you,
you
really
wanted
these
two
entities
to
be
separate
because
that's
informs
what
you
can
do
with
them.
F
H
G
Again,
in
our
case,
we
actually
did
pretty
much.
We
pretty
much,
don't
have
a
span
that
is
operated
on
in
any
way,
because
it
would
be
too
much
of
a
pain
because
we
don't
have
mutable
variables,
so
you
need
to
assign
new
variables
every
time
you
update
add
an
attribute
or
something
so
we
pretty
much
did
get
rid
of
this
band
and
it's
api,
but
it's
still
kind
of
there.
G
If
you
really
want
it,
but
we
still
needed
spam
context
span
reference
in
some
form,
so
I
find
spam
those
that
to
be
more
needed
on
the
user's
side
than
a
span,
and
that's
I
mean
that
that's
where
most
of
the
confusion
and
issues
with
the
api
has
come
from
from
users
is
when
they're
trying
to
use
spam
context
first
context
and
but
I
think,
yeah,
the
naming
we
can
just
power
through
with
span
context.
I
just
defining
it
really
well.
People
coming
from
open
tracing
might
be
confused
at
first,
but
yeah.
H
F
D
I
Didn't
realize
it
had
merged
yeah.
I
think
we
can
definitely
we
were
try.
We
got
enough
reviews,
but
the
problem
I
realized
later
is
that,
even
though
a
lot
of
people
were
paying
attention,
some
poor
key
players,
which
is
basically
me
means
maintainers,
didn't
have
time
to
review
that.
So
I
am
all
in
favor
of
reverting
that
change.
G
H
D
Through
me,
propagand
span
is,
I
think,
an
okay
solution
to
a
problem
that
doesn't
have
great
solutions
it
I
may
be.
Maybe
the
name
could
be
improved,
though
so,
and
I
think
that
that's
something
we
could
also
consider.
The
best
that
we
might
be
able
to
do
here
is
to
keep
the
namespan
context
and
explain
it
very
well,
using
those
words
identifier
and
reference,
it's
not
quite
a
reference,
but
it
is
kind
of
a
kind
of
set
of
identifiers,
and
that's
why
I
say
I
think
we
can
solve
this
problem
with
words.
D
So
I
want
to
remind
you
that
rename
this
one
has
merged,
but
we
might
undo
it
clarify
purpose
of
propagating
span
needs
words
modify
is
remote
from
span
context
to
spam.
That's
completely
present.
In
this
whole
conversation,
we've
had
and
make
stand
contacts
optional.
Three
of
these
issues
need
to
be
closed,
for
spec
updates
may
be
written
for
them,
and
I'm
concerned
that
we
really
just
talked
for
half
an
hour
and
left
with
no
more
resolution,
except
that
it
seems
we
should
keep
spam
contacts.
Yeah.
F
F
Right
so
it
would
be
good
to
maybe
just
review
these
other,
so
I
think
we've
settled
span
context
versus
spam
reference
if
we're
literally
just
renaming
existing
stuff.
We
should
just
not
do
that
at
this
point
and
just
such
is
life,
but
let's
dig
into
these
other
things
because
they
seem
like
they
could
have
more
going
on.
There,
we've
already
been
talking
around
propagated
span.
Maybe
we
should
move
past
that
to
the
is
remote.
B
Is
your
issue
as
well,
I
think,
I
think,
is
remote
is
sort
of
a
duplicate
with
the
propagated
spam.
Like
I
just
got
really
confused
by
the
word
propagated
spam.
I
thought
it
was
signaling
something
about
remoteness
which
prompted
that
idea,
but
if
it's-
but
that
was
my
confusion
there,
so
I
don't
think
we
should
move
his
remote.
D
Okay,
I
I
think
it
does
sort
of
call
for
a
few
changes
in
the
wording
of
the
spec,
but
thank
you
does
anybody
else
agree
that
the
placement
of
israel
could
could
conceptually
equate,
with
the
instant
being
an
instance
of
propagated
span
and
therefore
that
it
could
become
a
span.
D
H
F
If
we're
not
merging
span
context
into
span,
then
this
should
stay
on
the
context
object
because
that's
where
the
identifiers
are
yeah,
I
think
you
know
christians
has
the
best
point
on
this
thread,
which
is
it's
helpful.
The
the
core
use
of
that
is
remote
is.
Did
I
generate
this
these
ids
or
have
I
gotten
these
ids
from
somewhere
else?
Like?
Can
I
trust
this
fan
id
or
not,
and
that's
important
to
be
able
to
know,
but
you
couldn't
really
separate
that
from
the
object
that
has
the
span
id
on
it
right.
D
F
Oh
I
mean
like
th.
This
is
not
an
is
remote's,
not
part
of
the
trace
contact
spec,
that's
just
something
we're
using
where,
if,
if
that
span
is
populated
from
from,
if
that
span
is
created
from
identifiers
that
were
extracted,
that
that
is
different
from
a
span,
that
was
where
the
ids
were
and
everything
were
generated
internally
right.
So
that's
that's
like
a
subtle
distinction,
but
it
does
matter
from
time
to
time
for
people.
D
D
Okay,
so
I
guess
we
could
just
close
this
since
I
have
this
underlying
belief.
This
span
equals
span
context
of
the
issue.
As
of
73
states,
I
don't
care
whether
this
function
is
in
span,
context
or
span.
It
should
behave
the
same.
H
F
C
Honorable,
do
you
think
we
should
change
this
back
in
any
way?
I
don't
think
so
not
for
this
issue.
Okay,
do
you
think
that's
okay
to
close
it
right
now,
yep
yeah.
F
Okay,
so
now
we're
moving
on
to
make
spam
context
optional
with
the
intriguing
issue
number
of
999
anarag.
Do
you
wanna?
Do
you
wanna
pitch
us
on
this
one.
B
F
D
F
And
is
propagated
span,
and
is
this
a
external
concept
or
is
this
an
sdk
concept
right?
This
is
sdk
level
right.
I
I
Yeah
yeah
yeah,
that's
the
thing
so
currently
in
specification.
We
are
allowing
languages
to
actually
expose
this,
but
we
can
probably
advise
everybody
to
abstract.
D
H
D
Stuff
in
the
hotel
go
that
looks
that
same
way,
because
it
just
doesn't
make
sense
to
like
add
another
entry
point
that
you
might
want
to
configure
when
there's
really
only
one
natural
implementation
in
some
sense.
A
It's
kind
of
akin
to
the
way
baggage
is
now
that
it's
a
you
know
it's
a
fully
propagatable
structure
that
is
implemented
in
the
api.
I
G
H
D
So
that
was
so.
That
was
my
question
and-
and
my
question
then
goes
one
step
further,
which
is
as
an
sdk
for
metrics.
Can
I
intercept
that
non-recording
propagated
span,
which
might
have
a
duration
measurement,
or
when
I'm
doing
that,
do
I
have
to
create
my
own
concept
with
spam
and
at
some
level
this
concept
of
a
spam
is
probably
a
spam.
It's
just
a
conceptual
device
we're
using
to
write
a
specification
and
nothing
more.
It
doesn't
actually
have
to
exist
in
an
api.
D
I
G
I
Yes-
and
this
is
where,
in
java
at
least,
we
are
doing
use,
we
are
just
exposing
these
spam
group
methods.
A
A
B
B
H
I
don't
know
why
we
need
the
concept,
though
I
mean
the
only
reason
that
exists
is
so
that
you
can
stash
it
in
the
context
using
only
the
span
api
right,
so
it
could
be
just
an
anonymous
class
for
a
week
here
like
this,
like
the
wrap
method,
makes
more
sense
to
than
the
like
fully
named
propagated
span.
I
Yeah
we
can
expose
only
the
met
like
the
operation
instead
of
the
actual
concept
or
propagated
span.
B
D
Be
something
like
when
you
extract
your
your
return?
Value
is
a
span
or
a
contact
which
has
the
following
requirements
met,
and
then
you
list
what
that
behavior
is.
It's
got
the
same
identifiers
as
as,
though
it
were
a
reference
to
the
parent
context
on
a
remote
machine,
usually
et
cetera,
et
cetera,.
H
D
F
G
D
So
yeah
self-inflicted-
I
I
agree:
does
anyone
here
think
that
we
have
these
stomachs
to
undo
propagated
span
and
get
back
to
having
the
problem
that
I
have
is
that
when
I
did
an
extract
and
go
back
in
the
day
when
we
have
span
contexts,
I
get
actually
multiple
values
back
I
get
something
that
has
a
distributed
context,
which
includes
baggage
plus,
I
get
a
span,
object
and
or
sorry
expand,
context
object,
and
I
need
to
carry
both
of
those
to
the
point
where
I'm
going
to
create
a
child
span.
D
D
G
G
D
H
D
So
it
seems
like
there
is
a
viable
solution
here
where
we
go
back
to
having
two
contact
keys
and
I
I
don't
think
we
can
decide
that
here
or
we
have
enough
of
a
quorum,
but
I
I
recognize
it
as
a
valid
approach.
One
is
one
conscious
key.
Is
the
remote
span
context
and
one
context
key
is
the
current
span
and
to
me
this
just
requires
a
lot
of
like
language.
D
About
saying
when
I
extract,
I
think
the
correct
behavior
probably
is
to
provide
me
with
a
to
reset
the
current
span,
so
that
I
don't
have
current
span
is
some
http
connection
setup
span,
it's
a
local
span
and
the
new
span
is
going
to
be
the
remote
continuation,
I'm
leaving
the
server
context
and
entering
the
client
child
span.
Context
that
moment
between
extract
and
start.
Should
I
have
an
active
span
there.
D
That's
the
thing,
that's
probably
going
to
expand
right
now.
You
could
also
have
it
be
an
into
completely
independent
span,
which
is
and
and
then
there's
this
moment
of
confusion.
If
you
have
two
context
keys,
there's
this
moment
of
confusion
between
extract
and
start
where
you
have
a
remote
parent
span
and
a
local
current
span,
and
that
can
be
worded
out.
But
it
is
a
corner
case
that
gets
pretty
confusing.
So
I
would
suggest
that
the
default
behavior
should
be
when
you
extract
you
could
you
you
set
the
current
remote
parent
and
you
reset.
D
I
It,
sadly,
we
don't
have
bogdan
here.
He
was
a
big
supporter
of
these,
but
we
can
propose
that.
D
See
I
know
matt
ware
who's,
also
not
on
the
call.
He
is
also
was
one
of
the
ones
who
spiked
into
that
question
about
how
to
handle
the
15-20
lines
of
code.
That
takes
the
contacts
and
the
fan,
contacts
and
or
two
contest
keys
and
and
like
I
could.
I
could
try
to
assign
that
to
another
live
server
who's,
not
on
the
call,
that's
an
easy
way
to
solve
this
problem.
But
I
don't
know.
G
D
Anyone
here
have
a
feeling
about
zipkin
compatibility,
there's
this
note
that
I
feel
like
put
somewhere
where
sleepkin
has
this
practice
of
when
you
extract
that
moment
between
extract
and
start
you're,
actually
in
a
continuation
of
your
parent
span,
essentially
where
those
annotations
that
happen
will
ultimately
be
joined
with
the
sort
of
the
remote
endpoint
side
of
a
client-side
span.
G
D
G
D
D
My
conception
of
it
is
that
there's
sort
of
simple
trace
graph
that
you
can
create
with
parents
and
children
in
a
in
a
tree.
But
when
you
talk
about
an
rpc
system,
those
edges
that
are
non-local
between
a
type,
a
parent
and
a
child
in
an
rpc
system,
those
edges
usually
have
other
details,
like
you
know,
request
size
or
target
hostname
or
some
sort
of
peer
annotation.
D
I
I
think
zipkin
is
structured
to
kind
of
piece
together
its
traces
according
to
those
those
essentially
having
four
different
types
in
an
rpc
transaction.
The
client
side
send
requests
the
client
side,
receive
the
service
side
start
and
the
server
side
finish.
D
H
Well,
so
jaeger's
decay
supported
zipkin
model
without
really
that
it's.
The
only
distinction
is
that
if
you
configure
a
jager
sdk
to
be
in
zipkin
mode
where
client
and
server
have
both
identical
span
id,
then
that's
the
only
distinction.
You're
basically
saying
yes,
I
have
a
remote
span
id
I'm
starting
new
spam,
but
I
happen
to
inherit
the
id,
but
it's
still
it's
like
it's
a
local
spam
object.
So
beyond
that,
there's
no
distinction
really.
G
Well,
when
I
asked
who
is
it
what's
his
name
adrian
or
aaron
hall
yeah?
Why
why
his
parents
fan
id
propagated?
G
He
just
linked
to
something
that
says
the
parent
band
id
is
propagated
because
that's
how
you
get
it
in
the
correct
spot
in
the
trace
tree.
So
I
asked
for
an
example
or
explanation
of
how
this
happened
and
how
that
would
happen,
and
I
he
never
replied.
H
Oh
no,
I
can
explain
that,
but
again
that
stems
from
the
single
span
model
that
they
use
for
both
sides
of
our
pc,
and
so
when
you're
creating
a
server-side
span.
H
Literally,
the
ids
of
that
span
have
to
be
identical
to
the
client-side
span,
including
the
parent
id,
because
you
could,
like
you,
could
set
parent
id
to
zero.
I
think
zipkin
might
still
work
with
that,
because
the
key
for
the
object
is
really
just
the
span
id
in
the
database,
but
then
the
zip
conserver
would
have
to
do
a
bit
more
work
to
figure
out
what
the
real
parent
id
is,
and
so
they
just
say
and
basically
propagate
it
and
save
it
as
part
of
the.
G
G
D
Okay,
this
is
definitely
a
tangent
from
the
topic
at
hand,
so
I
think
also
that
we're
at
the
end
of
our
I
don't
know
that
we've
resolved,
although
we
did
close
some
issues,
I
think
well,
I'm
going
to
reach
out
and
see
if
we
can
find
somebody
who
wants
to
file
an
issue.
Well,
sorry
trusting
you
said:
you'd
file,
an
issue.
What
I'll
do
is
as
I'll
ask
you
to
go
ahead
with
that
plan
and
then
I'll
ask
some
people
I'd
step
to
add
their
opinions.
If
that's.
D
F
D
Yep,
okay,
thanks
everybody,
especially
honorable
and
yuri,
who
I
vote.
I
requested
here
thank.