►
From YouTube: 2020-09-28 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
B
B
D
D
D
E
E
Sure
I
just
wanted
to
start
off
with
just
a
quick.
Let
me
see
a
point
about
the
progress
we've
been
making
in
general.
Looking
back
from
the
ten
thousand
point,
ten
thousand
foot
view:
we've
had
a
lot
of
activity
in
the
past
two
months
on
the
open,
telemetry
specification
repo.
E
So
I
just
want
to
recognize
that
and
say
that
everyone's
been
working
quite
hard
for
the
progress
and
it's
very
much
appreciated
for
the
progress
of
the
community
towards
ga-
and
I
know,
accounting
like
github
commits
is
not
exactly
the
best
metric,
but
it
is
a
needle
that
does
show
there
has
been
more
activity
on
that.
E
So
just
want
to
acknowledge
that
that
being
said,
moving
on
to
our
status
of
where
we
are
for
our
most
immediate
milestone
of
freezing
the
trace
spec,
so
I
posted
details
in
the
getter
channel
for
open
telemetry
specification
on
what
we
worked
on
last
week
in
order
to
scrub
the
remaining
issues.
At
one
point,
we
had
brought
all
the
to
do
items
and
in
progress
items
to
zero
for
p
ones
that
were
blocking
the
freeze
for
trace
spec,
which
was
a
significant
milestone.
E
I
think
it
was
like
on
the
thursday
or
something
like
that
and
on
the
friday,
during
the
triage
meeting,
we
also
identified
some
p1
issues
that
I
think
it
even
though
we've
got
the
spec
meeting
tomorrow.
If
we
could
spend
some
time
maybe
going
over
today.
That
might
be
a
helpful
thing
towards
philosophy.
If
we
have
the
people
necessary
to
talk
about
the
technical
aspects
of
these
issues,
so
let
me
see
the
spec
burn
down.
Specifically,
I
updated
this
this
morning.
E
So
as
a
result
of
the
scrub,
as
you
can
see,
we
have
the
p1
issues
that
are
not
labeled
as
spec
metrics.
These
two,
I
think,
between
the
two.
F
The
first
one
is
I'd,
say
almost
decided,
so
we
don't
need
much
time
for
that.
So
it's
really
the
second
one
which
logan
opened
on
friday.
That
one
requires
more
time
and
thought.
So
I'd
really
like
to
understand
how
much
time
we
need
for
this,
because
that's
the
only
thing
that
is
necessary
to
complete
for
those
just
one
issue.
G
And
from
the
java
side,
we
would
like
to
make
a
plea
for
the
the
spec
issue
that
honorag
had
opened
last
week
and
he
submitted
a
poll
request.
I
put
it
in
the
notes
in
the
meeting
maintain
our
meeting
notes.
It's
a
one-line
thing
that
allows
us
to
merge
the
make
it
clear
that
we're
allowed
to
merge
the
span
context
attributes
into
the
span.
C
G
Yeah
honorable
already
submitted
a
pr
for
this
to
the
java
repo.
So
that's
that's
how
I
mean
yeah
and
it's
really
it's
a
really
nice
pr
really
cleans
up
a
lot
of
stuff
for
us.
So
that's
why
we'd
like
to
get
but
bogdan
correctly,
you
know
reasonably
blocked
the
pr
because
said
that
you
know
we
should
take
it
to
the
spec.
G
So
that's
we
would
like
to
take
it
to
the
spec.
Okay.
B
Yeah,
so
personally,
that
we
are
only
making
something
optional
that
was
required
before
all
the
others
implemented
it,
so
there
is
no
burden
on
any
sick
other
than
the
javasig
if
they
want
to
do
it.
So
from
a
spec
perspective,
I
do
not
think
that
we
need
to
block
this.
I
It
has
to
be
yeah,
but
but
if
we
want
to
kill
off
span
context
as
a
concept,
we
need
to
do
that
now
before
ga.
So
that's
to
me
is
the
real
question.
I
agree:
there's
no
real.
I
don't
see
any
real
reason
why
a
language
couldn't
expose
these
as
convenience
methods,
but
it
would
be
nice
to
eliminate
spam
context
entirely.
If
this
is
a
thing,
we
don't
have
any
need
to
expose
to
end
users
anymore,
and
I
know
bogdan
that's
a
thing
you've
been
playing
around
with
right
for
me
for.
J
Me
mostly,
was,
I
don't
think
I
I
I
aim
for
consistency
across
languages,
even
though
we
give
a
lot
of
freedom,
but
when
it
comes
to
some
of
the
concepts
that
we
inspec,
we
we
mention
a
lot
like
span
context.
It
will
be
very
hard
if
one
of
the
languages
does
not
have
that
concept.
In
my
personal
opinion,
so
I
think
to
remove
that
it
should
be
removed
across
the
entire
specs,
not
only
in
java.
It's
a
personal
yeah.
I
J
J
H
J
That
that
may
be
fine,
I
mean
I
also
filed
a
separate
issue
that
may
require
us
to
postpone
the
phrase.
I
think
I
think
what
what
we
should
get
these
threes
for
me.
For
me,
this
phrase
means
unless,
unless
you
identify
an
issue
right
now,
we
do
not
accept
any
new
things
like
if
somebody
comes
and
say
a
dysfunctionality,
we'll
say
no,
but
if
somebody
says
okay,
because
there
were
a
lot
of
issues
emerge
thursday,
wednesday.
J
Yes,
but
this
major
change
came
as
an
effect
of
another
pr,
so
as
as
anurag
explained
we
merged
wednesday,
I
think
we
merged
a
pr
that
was
removing
something
from
the
context
and
were
introducing
the
concept
of
propagation
span
and
stuff,
and
that's
what
enabled
this
thing
so
so.
To
be
honest,
I
think
it's
a
side
effect
of
that
for
it,
and
also
my
my
issue
around
context
is
a
side
effect
of
the
fact
that
I
think
thursday.
J
We
merge
the
trace
context
to
teal
part,
and
now
we
have
a
duplication,
and
I'm
complaining
about
that
thing.
So
I
I
think
these
are
side
effects
of
things
that
were
merged
in
the
previous
week,
and
I
think
we
should
have
the
ability
to
clarify
this
and
if
we
find
bugs
while
we
implement
them.
H
So
I'm
fine
with
that
removing
spam
context.
I
think
it's
gonna
take
longer
for
sure.
I'm
fine,
if
everybody's
fine
with
postponing
things.
I
don't
think
this
is
so
simple
honestly,
because
that's
my
point.
J
Let's
give
us
a
couple
of
days
at
least
to
put
down
the
pros
and
cons
for
both
in
in
the
pr
and
make
a
decision
once
we
we
see
the
the
pros
and
cons.
C
J
We
can
try,
let's
start
starting
the
meeting
and
see
where
we
go,
and
maybe
that's
good
enough
anyway.
J
C
Filed
you
also
follow
an
issue
bugged
in
context,
interaction,
different
packages
like
trace
baggage,.
E
So
the
only
other
item
that
we
weren't
able
to
complete
last
week
that
we
were
aiming
to
complete,
was
figuring
out
which
part
of
the
compliance
matrix
is
required
to
it's,
not
super
burning
urgent,
but
this
is
needed
for
the
languages
in
order
to
understand
what
they
need
to
implement
in
order
to
be
able
to
satisfy
implementation.
E
But
we
can
work
on
that
in
parallel.
These
other
items
of
are
related,
I
believe,
to
pertinent
discussions.
So
I
will
increase
my
time.
J
Okay,
so
if
you're
done-
let's,
let's,
if
somebody
can
present-
and
let's
start
with
that
protocol
change,
which
is
the
simplest
one.
H
J
I
think
this
one
is
one
of
the
two
marked
with
p1
items
that
we
probably
need
to
fix.
I
haven't
had
a
chance
to
read
on
this.
F
It's
pretty
simple:
well
done:
do
we
want,
by
default
the
protocol
to
be
insecure,
or
do
we
want
by
default
it
to
be
secure?
The
implications
of
making
it
secure
by
default
is
that
it
no
longer
works
out
of
the
box
when
you
connect
to
a
local
host,
because
normally
there
is
no
certificate
installed
on
the
localhost
server,
so
you
have
to,
in
that
case
either
either
say
that
explicitly
say
that
you
want
it
to
be
insecure
or
you
have
to
use
certificates
which
basically
favors
security
over
convenience.
J
F
And
that's
the
the
current
state
of
things
we
the
specification
says
that
the
default
should
be
insecure,
equals
false,
that's
not
equal.
So
if
that's
the
decision-
and
I
don't
see
anybody
posting
an
opposing
opinion
to
that-
then
this
is
we
just
closed
this.
No
no
action
on
this.
We
can
keep
it
open
for
another
day
if
there
is
a
desire
to
hear
more
opinions
and
then
close,
it.
C
F
G
I
think
what
you
gain
is
confu
lack
of
user
confusion
where
they
try
to
just
you
know,
use
the
default
out
of
the
box
and
it
doesn't
work
versus
if
we
force
them
to
set
the
host.
In
the
first
place,
then
they've
seen
the
docs
they've
seen
where
they
have
to
set
both
the
host
and
this
insecure
setting.
M
So
it
seems
like
either
case
the
default
wouldn't
work
out
of
the
box.
There,
though
there
is
a
slim
chance
that
someone
could
have
tls
set
up
on
localhost
and
it
might
work
out
of
the
box,
can
I
can.
I
have.
F
J
I
think
it's
kind
of
combined,
so
what
he
says
is
we.
We
have
a
default
localhost
where
we
expect
the
default
for
security
to
be
insecure,
because
you
don't
necessarily
need
security
between
between
two
jobs
on
the
same
host,
and
so
that
may
explain
why
insecure
equals
true
may
make
sense
in
combination
of
a
default
of
endpoint
equals
localhost.
F
J
F
It's
not
a
url,
it's
a
host
name.
The
endpoint
is
not
the
full
url
there's.
No,
it's
not
prefixed
by
http
or
https
or
whatever.
M
J
F
F
I
So
what
I
suspect
is
happening
is
if
you
tried
to
talk
to
a
web
browser,
this
wouldn't
work,
but
that's
not
necessarily
the
case
that
the
collector
couldn't
run
grpc
without
tls,
so
that
might
be
a
place
to
check
as
far
as
why
is
it
currently
working.
F
I
Yeah,
might
it
might
be
good
to
just
validate
whether
we're
running
over
ssl,
but
just
not
bothering
to
validate
the
certs
or
whether
we're
actually
genuinely
running
over?
Well,
I
guess
you
can't
run
over
http,
but
that'd
be
good
to
check
in
on.
J
Okay,
so
should
we
spend
more
time
on
these,
I
think
we
collected
a
bunch
of
ideas.
We
even
are
you
good
with
this
or.
F
Yeah,
I
suggest
we
we
move
on
because
the
other
one
is
more
important
in
my
opinion
and
we'll
require
more
more
discussion.
I
can
take
care
of
this
one
offline.
J
J
It's
it's
about
the
fact
that
we
merged,
I
think,
thursday
or
wednesday.
This
pr
that
adds
new
a
new
thing
called
trace
context
utilities
which
define
a
way
to
to
interact
with
the
currently
active
span
or
how
I
call
it
the
span
in
the
current
active
context,
because
the
context
is
active.
The
span
is
just
in
that
context.
Okay,
so
the
span
in
the
current
active
context
you
retrieve
it
and
you
are
able
to
set
which
is
fine,
but
then
three
lines
or
five
lines
below
there
is
another
option
on
the
tracer.
J
So
for
me,
just
by
reading
these,
I
was
very
confused
and
I
think
the
problem,
the
first
problem
that
I
found
was
we
in
this
inside
the
tracing
api,
will
have
two
ways
to
to
achieve
the
same
thing
needed
to
say
that
there
is
a
third
option
which
will
be
you
manually
grab
the
current
active
context
with
the
with
the
context
option.
So
the
context
also
has
an
operation
to
extract
the
current
active
and
you
can
from
this.
You
can
extract
the
the
spam.
J
So
there
are
currently
three
options
for
us
to
achieve
the
same
thing
that
that
was
the
first
red
flag,
the
second
flag
that
I
I
found
while
investigating
this
was
currently
we
don't
have
documented.
J
Okay,
so
yes,
it
is
recommended
here
it
is
so
in
the
context
we
say
that
is
not
recommended
to
provide
access
to
the
key,
and
I
can
explain
you
why
this
is
a
good
thing
and
we
had
a
clear
example
in
open
senses
where
we
got
hit
by
this.
So
this
is
a
good
thing
to
not
expose
publicly
the
key
directly
and
expect
expect
expose
rather
helpers.
That
will
say
from
car
from
from
a
contest
in
context
instance.
Give
me
the
spam
from
a
context
instance.
Add
this
pan
and
return
me
another
context.
J
Instance,
that's
that's
very
fine!
Okay,
but
now
we
do
not
have
in
the
tracing
pi
anywhere
documented
thinks
about
the
context
key.
We
do
not
say
how
if
we
expose
the
key
or
not-
and
we
do
not
say
where
these
helper
methods
will
will
leave
and
that's
why
I
try
to
file
the
bug
the
each
the
pr
here
there
is
a
pr
where
here
there
is
a
pr
where
I
tried
to
say:
okay,
let's,
let's
think,
to
put
a
key
inside
this
contact
tracing
context
to
utilities.
J
J
I
I
have
thought
about
different
solutions.
First
question
was:
do
we
really
need
these
helpers
that
we
have
now
right
now
defined
twice
some
people?
They
believe
they
are
useful.
Some
may
may
believe
they
are
not
useful.
This
is
the
first
question
that
we
we
have
to
answer
here.
J
H
J
H
What
I
have
a
question,
what
are
you
doing?
Sorry?
Yes,
I'm
done
so.
My
understanding
is,
you
is
that
you
really
want,
or
it
was
that
you
really
wanted
to
remove
active
or
get
korean
spam
and
with
spam
from
the
tracer
class.
Is
that
correct.
J
J
J
J
So
even
if
we
provide
a
helper
like
that,
it
should
be
only
in
one
place,
then
the
second
part
is:
do
we
really
need
this
helper,
and
I
think
I
think
I
can
see
pros
and
cons
to
have
this
helper,
and
you
pointed
to
me
one
example
where,
where
this
is
useful-
and
we
can
chat
about
that-
but
first
of
all
I
want
to
to
kill
one
of
these
voting
like
from
the
tracer.
H
Or
from
the
context
to
deal
I
see,
okay,
interesting
makes
sense.
F
J
J
There
is
a
good
question
of
if,
if
the
the
the
functionality
of
current
active
span,
current
active
context
is,
is
a
global
thing
or
is
a
is
a
injectable
thing,
because
if
it's
injectable
the,
then
you
still
need
to
pass
somehow
an
instance
of
the
injected
implementation
of
that.
So
so
that
may
change
things.
J
You
have
to
to
keep
that
in
mind
that,
for
example,
this,
if
we
put
them
here
in
the
tracer,
if
we
leave
only
here,
this
makes
kind
of
some
sense
because,
as
I
explained,
the
issue
for
me
context
is,
has
multiple
parts.
One
part
is
just
the
context
itself,
which
I
don't
think
there
is
a
good
argument
to
have
that
injectable
or
not
just
the
context
itself
is
a
simple
map.
It's
it's
not
something
that
we
need
to
worry
too
much
about
having
that
injectable.
I
Can
I
make
a
suggestion
here
sure
so,
the
the
the
main
impetus
behind
these
utilities,
as
you
mentioned,
has
to
do
with
naming
and
retaining
a
handle
to
a
tracer
which
is
honestly
no
big
deal
if
you're
writing
instrumentation
plug-ins,
and
in
fact
you
absolutely
should
do
it
that
way.
The
question
is
really
about
application
developers
writing
application
code.
That's
where
both
having
to
grab
and
name
a
tracer
is
like
a
just
weird
concept
for
application
developers
and
then
having
to
hold
on
to
it
somewhere
is
also
really
painful.
I
You
end
up
with
just
a
ton
of
classes
having
to
do
this,
potentially
or
at
least
a
lot
of
confusion
on
the
part
of
the
end
user.
So
one
way
to
solve
this
that
would
still
make
things
very
easy
for
the
application
developer,
but
not
split.
These
methods
off
of
the
tracer
is
to
instead
have
a
default
tracer
named
application,
or
something
like
that
and
to
say
that
application
developers
should
just
grab
this
default
tracer.
I
That
then
makes
the
tracer
instance
still
be
a
tracer
instance.
There
isn't
anything
weird
or
special
happening
there,
and
if
you
have
to
click
application
developer,
you
grab
the
default
tracer
and
it's
really
easy
to
then
wrap
that
up
in
helper
methods.
If
you
just
want
to
literally
say
helper
dot
get
current
span
because
you're
lazy,
you
can
do
that.
But
you
don't
end
up
in
this
weird
situation
where
the
tracer
instances
are,
depending
on
some
global
context,
utility
or
something
kind
of
weird
like
that.
I
I
Part,
I
I
think
it
is
fine
for
us
to
ship
helper
methods
at
some
point
if
we
want
to
ship
a
package
of
just
like
helper
methods
that
make
common
things
one-liners.
That's
one
thing:
I
am
a
little
weirded
out
about
doing
it.
This
way
where
these
utilities
are
not
high
level
functions
like
this
is
actually
the
low-level
way
that
you
do
it
and
you
can't
go
around
this
helper
function,
and
then
we
have
object
instances
that
are
relying
on
it
that
that
part
seems
weirder
to
me.
I
J
What
about
the
context
key?
Where
is
that?
Where
is
that
exposing
functionality
around
context
key
which,
which
is
lacking
right
now?
I.
I
Would
personally
yeah,
I
would
vote
to
keep
that
hidden
for
now,
if
possible.
I
liked
your
suggestion
that
we
shouldn't
be
handing
those
out
people
shouldn't
be
grabbing
into
the
context
on
their
own.
It
should
always
be
through
a
layer.
Yes,.
J
But
is
that
layer
also
part
of
the
tracer?
Do
we
have
so
so
we
need.
We
need
two
functions,
and
these
two
functions
are
doing
this.
This
thing,
like
I'm,
giving
you
a
context
instance
grab
me
the
span
from
it
and
I'm
going,
I'm
giving
you
a
context
and
a
spam.
Give
me
another
context
that
has
everything
else,
except
plus
a
new
span
and
doesn't
have
the
old
span
or
whatever.
I
A
G
So
what
about
keeping
tracing
context
utils,
but
not
having
them
know
about
like
having
those
methods
require
the
context
to
be
passed
in
to
them.
L
G
That
way,
you
know
the
tracer
one
could
be
built
on
top
of
that
and
we
still
have
that
still
protects
the
key
and
we
can
still
use
that
directly
to
interact
with
the
context.
J
N
I
added
a
comment
onto
this
issue
kind
of
with
maybe
like
an
alternate
proposal,
and
that
is
that
for
me,
it's
natural
for
the
span
operations
to
go
through
the
tracer
either
tracer
instance,
or
the
tracer
class,
or
your
kind
of
equivalent
and
having
a
method.
A
tracer
current
span
method.
That
optionally
takes
a
context
defaults
to
the
current
context.
If
it,
if
you
haven't
passed
one
end,
so
this
could
be
an
overload
in
in
other
languages
kind
of
gives
you
the
best
of
both
worlds.
N
G
I
think
this
yeah,
so
I
think
this
is
the
same
as
what
we
were
saying
with
the
addition
of
having
the
underlying
util
class
that
this
is
built
on,
which
the
reason
I
like
to
have
that
a
way
to
interact
with
the
context
outside
of
the
tracer
is
that.
G
We
do
a
lot
of
context,
propagation
that
it
doesn't
like
in
in
java
around
like
react
and
thread
pools,
and
things
like
that,
where
there's
no
concept
of
tracer,
because
we're
not
creating
spans
we're
just
pure
context,
propagation.
J
J
G
J
J
N
J
I
don't
auto
instrumentation
should
do
that.
I'm
more
worried
about
somebody
during
the
transition,
for
example,
from
brave
to
to
open
telemetry
will
where,
where
some
of
the
the
things
are
using
brave,
they
can
still
do
a
shim
from
from
open
telemetry
to
brave
in
zipkin,
brave
and
half
of
the
code
working
with
that
half
of
the
code
working
with
the
new
sdk
and
because
of
this
they
need
in
process.
I
I
would
strongly
suggest
that
we
not
add
the
complexity
needed
to
support
multiple
underlying
implementations
interrupting
with
each
other.
I
feel
like
you
will
end
up.
The
whole
point
of
a
lot
of
this
work
is
to
not
expose
a
lot
of
public
api,
so
we
can
keep
a
lot
of
room
around
the
implementation
varying
around
a
lot,
and
I
think,
if
we
try
to
make
implementations
publicly
interrupt,
then
you
would
basically
undo
a
lot
of
that
work
in
a
lot
of
ways.
J
N
J
J
J
N
J
Anyway,
for
me
for
me,
I
like
this
option
and
then
and
then
arguably
arguably,
we
don't
actually
need
to
have
the
key
inside
the
api
or
do
we,
I
think
we
have
for
propagation
only
we
have.
We
still
have
to
have
the
key
inside,
but
I.
I
I
The
trees
and
I
really
think,
having
looked
at
this
more
that
just
having
a
default
tracer
rather
than
exposing
some
globals
or
other
things
like
that,
would
solve
the
application
users
issue,
probably
better,
and
it
also
means
we
don't
have
to
explode,
expose
things
at
that
level.
You
know
if
you
want
to
use
a
global
under
the
hood
or
a
thread,
local
or
something
you
can,
but.
J
One
problem,
one
problem:
if
the
key
belongs
to
the
tracer,
our
propagator
api
is
wrong.
Our
propagator
api
does
not
accept
the
tracer
instance.
Our
propagator
api
accepts
only
a
context,
and
it
has
to
have
a
global
way
from
that
context.
To
extract
the
the
span.
I
So
yeah
you
have
to
set,
you
have
to
add:
it's
like
the
tracer
has
to
be
able
to
generate
a
propagator
implementation
like
or
something.
M
I
Would
that-
and
I
guess
what
I'm
saying,
though,
is
you,
don't
necessarily
need
to
expose
these
keys?
If,
if
what
you're
propagating
is
not
tracing,
then
not
only
are
you
not
the
tracer,
you
don't
need
the
tracing
keys.
J
So
so
we
we
say
and
again
sorry
for
for
ignoring
the
previous
comment
about
metrics,
but
I
think
that
problems
is
the
same
problem
but
with
baggages,
and
we
right
now
discuss
about
tracing,
but
we
will
apply
the
same
things
for
the
baggage.
It
has
the
same
problem
with
the
key
and
everything.
J
So,
let's,
let's
focus
on
this,
somebody
wants
to
implement
a
b3
or
a
live
step,
propagator
right
now,
if
we,
if
we
expose
this
on
the
tracer
and
we
don't
have
another
way,
another
global
thing,
or
something
just
to
extract
from
a
context
instance.
So
if
I
remember
correctly,
let
me
push
this
because
in
the
specification
in
the
context
there
is
this
thing
carrier
operations.
I
G
I
I
C
I
J
J
I
J
I
Yes
right,
but
but
if
you
could,
if
you
automatically
set
up
a
default
tracer,
then
that
that
solves
that
problem
too.
That's,
I
guess
what
I'm
saying
is.
I
don't
think
we
need
to
to
go
if
what
we
need
is
probably
more
something
that
looks
like
a
global
tracer
rather
than
starting
to
pull
methods
off
of
the
tracer
class,
and
I'm
just
thinking
about
all
the
other
things
that
application
developers
may
want
to
do.
I
They
may
want
to
create
a
child
span
that
that's
a
pretty
common
thing
to
do
in
your
application
code,
but
they
would
have
the
same
issue.
They
don't
really
want
to
build
a
tracer
right
then,
in
there
just
to
to
create
a
child
span,
and
they
definitely
don't
need
to
to
name
all
of
these
tracers
after
the
individual
classes.
That's
not
really
the
point
of
what
we're
trying
to
do
with
the
name.
Tracers
yeah.
G
But
the
tracer
api
can
support
creating
a
propagator
and
then
it
already
knows
the
key
and
it
doesn't
have
to.
We
don't
have
to
expose
this
the
with
span
or
anything
use
any
of
that
it
just
returns
a
propagator.
If
you
ask
for
a
text.
J
G
G
Yeah,
that's
what
the
tracer
would
be
responsible
for
saying
how
to
do
it,
how
to
extract
the
span
context
from
the
content.
The
spam
context
from
the
context
the
tracer
would
create
a
propagator
based
on
that
and
b3
implementation
doesn't
have
to
know
anything
about
context.
It
just
has
to
know
how
to
decode
headers
and
it
can
return
a
span
context
that.
J
G
Yeah,
I
know
I'm
saying
the
the
the
the
method
like
that
creates
a
propagator
and
the
tracer
works
on
a
context.
But
what
it
passes
to
this
b3,
extractor
and
injector
is
not
the
full
context,
because.
J
I
It's
if
it's
all
happening
under
the
hood,
it
doesn't
matter.
You
know
your
tracing
propagator
can
make
a
you
know.
If
you're,
not
using
a
spank,
you
don't
need
to
necessarily
expose
a
span
context
object
to
to
add
this.
I
guess
is
what
I'm
saying.
I
don't
see
how
it
again,
you
don't
need
a
standalone
b3.
I
don't
believe
you
need
a
standalone,
b3
propagator.
H
I
J
I
In
my
mind,
I'm
trying
to
keep
the
keys
out
of
the
public
api
and
just
at
the
sdk
level.
Basically
that's
in
my
head.
That's
I
don't
want
people
to
see
that
in
the
api
and
be
like,
oh,
I
should
be
grabbing
at
these
things.
Maybe
it's
an
unfounded
fear
and
it
doesn't
really
matter
like
stuff.
We
would
love
to
keep
at
the
sdk
level.
J
The
other
things
you
need
to
remember,
even
though
java,
for
example,
may
offer
a
thread
local
propagation
for
context.
There
may
be
corner
cases
where
people
will
pass
a
context
instance,
for
whatever
reasons
they
won't
pass,
that
as
a
as
an
explicit
argument
to
a
function
for
for
just
to
not
install
it
to
the
thread
local.
If
it's
really
the
next
function,
because
that's
only
where
they
need
it,
it's
not
a
more
complicated
code.
It's
just
a
small
function.
J
I
It
seems
like
a
little
bit
of
a
separate
problem
from
whether
we
want
like
global
utilities
for
getting
at
the
span,
the
versus
a
global
tracer
or
a
default
tracer,
and
then
the
other
issue
you
brought
up
was
around.
I
You
know
what
matt
raised
around
like
what
does
the
api
look
like
for,
generating
and
interacting
with
spans
in
multiple
contexts,
and
it
seems
like
the
propagator
issue
and
whether
we
expose
keys
is
maybe
neither
here
nor
there
with
those
other
issues
like
the
thing
forcing
us
to
expose
those
keys,
if
it
is
has
to
do
with
the
fact
that
we
want
propagators
to
be
independent.
It's
not
really
related
to
the
other
stuff.
We're
talking
about
here,
tristan,
go
ahead.
G
Yeah
I'll
write
this
as
a
comment
on
there,
because
I
might
be
able
to
explain
it
better
but
yeah
to
me.
The
tracer
is
what's
creating
the
propagator
for
spans
and
it
should
be,
it
can
be
responsible,
b3
and
w3c
have
that
in
common
as
they're
used
for
tracing,
they
should
be
very
be
able
to
be
very
generic
and
just
the
tracer
is
responsible
for
it.
J
If
you
can
put
that
it
would
be
great,
that
being
said,
I
don't
think
we
solved
any
of
these
things
right
now,
but
I
hope
everyone
agrees
that
right
now
it's
a
lot
of
unclear
things,
and-
and
currently
we
have
to
fix
this
issue-
how
it's
still
to
be
decided.
We
have
two
more
minutes
and
I
want
to
just
briefly
touch
a
bit
about
the
merging
span
context
with
spam
thing,
and
so
we
will
continue
to
work
on
this,
but
I
want
to
briefly
touch
about
that.
I
And
my
only
real
advice
is,
I
do
think
with
these
changes
now
we
we
should
strive
for
the
least
amount
of
change
required
to
implement
the
thing
we
want,
just
because
I'm
worried
about
other
side
effects
it.
It's
one
thing
to
solve
these
issues
without
changing
our
structure,
and
then
you
can
feel
safe
that
you
fixed
your
issue
without
creating
new
issues.
But
if
we
start
changing
the
structure
of
these
things,
it's
not
totally
clear
what
else
we're
exposing
us
to.
I
J
That
last
week,
by
rushing
the
freeze
so
to
be
honest
last
week,
and
as
tristan
pointed
we,
we
rushed
a
lot
of
things
because
of
this
artificial
deadline,
which
personally
I
raised
this
issue
for
for
a
month.
They
said
that
we
will
get
into
this
trap
that
we
have
an
artificial
deadline
and
we
will
close
issues
without
carefully
thinking
about
all
the
things
I
I
pointed
this
for
for
a
month
or
so,
and
hence
this
happened
because
it's
it's
a
human
thing.
You
want
to
hit
the
deadline.
H
So
you
make
well
let
me
have
a
comment
and
say
that
in
all
due
honesty,
a
lot
of
these
issues
have
prototypes
and
a
lot
of
decisions
were
opened
and
they
were
merged
because
they
were
approved,
not
all
of
them,
but
a
lot
of
them.
They
were
there
open,
and
you
know
there
were
people
reviewing
them
like
for
so
many
days,
and
I
think
that
I
don't
know
what
to
say
honestly,
it's
like
if
we
had,
if
you
have
six
reviews
and
then
they
were
open
for
a
week
at
least
so
what
do
you
do?
H
J
J
If
there
are
things
like
this,
I'm
not
saying
that
we
should
do
anything
else,
but
I
think
is
normal
every
time,
because
that's
why
you
have
a
release
candidate
and
during
this
release,
candidate
phase,
you
may
find
problems
and
before
you
call
ga,
you
may
fix
some
of
these
problems,
and
I
think
this
is
the
the
missing
part
that
we
never
understood.
We
said
we
have
a
deadline
and
after
that
everything
is
freeze.
J
C
C
J
That's
okay,
that's!
What
I
want
is
is
don't
have
an
artificial
deadline
that
yeah
that
now
is
done
because
again,
some
issues
like
what
I
pointed
like
what
anurag
wants
to
to
to
do
may
still
worth
a
bit
of
discussion,
and
we
may
still
give
some
grace
period
of
couple
of
weeks
to
make
sure
we
are
not
rushing
things.
We
rush
until
this
deadline.
Fine
right
now
take
a
bit
of
time.
J
I
Yeah,
I
I
think
it
this
is
great,
but
yet
just
the
the
less
we
change
our
structure,
our
architecture,
the
the
more
confident
we
can
be
that
the
changes
we're
making
are
localized
right
right,
correct
errors
was
an
example
of
this.
Getting
rushed
right
where
we
were.
The
initial
approach
to
errors
was
around
we're
going
to
get
rid
of
status.
We're
going
to
you
know,
get
rid
of
reporting
errors
and
all
these
things,
and
that
was
creating
a
bunch
of
potentially
unknown
consequences.
I
And
then,
when
we
dug
into
it
more,
we
discovered
hey,
you
know.
Actually
we
can
make
everyone
happy
by
just
removing
a
couple
of
things.
So
I
think,
with
a
lot
of
these
remaining
things
like,
let's
just
be
suspicious
of
solutions
that
require
us
to
to
really
change
things
around,
because
I'm
a
little
suspicious.
We
would
need
to
do
that
to
get
to
ga,
I'm
sure
we
can
clean
things
up
and
make
open
telemetry
2.0
be
way
awesomer
than
this,
but
we
know
open.
Telemetry
1.0
is
going
to
work
given
its
current
state.
J
I'm
not
trying
to
revolutionize
the
world,
I'm
just
pointing
that
there
is
duplicate
functionality
and
there
is
some
missing
things
that
everyone
expected.
That
is
there,
but
is
not
documented
and
a
couple
of
things
like
that.
It's
not
again
it's
not
revolutionary,
I'm
not
adding
new
apis
and
stuff
again
about
this
trust
thing.
J
J
J
I
still
think
it's
useful
and
I
will
give
you
a
couple
of
things
to
think
about.
One
thing
is:
if
we
want
to
do
correlation
between
tracing
in
any
other
signal,
most
likely,
you
don't
need
to
pass
the
entire
span
for
that,
and
you
don't
need
to
reference
the
entire
memory
of
the
span.
J
G
Do
you
mind
if
I
take
that
one
point
at
a
time,
so
why
wouldn't
you
pass
the
span
to
la
the
log
mdc
than
if
it
can
take
an
object,
because
I
mean
users,
it's
weird,
I
mean,
then
users
are
just
they're,
gonna
call
dot,
trace
id
dot
span,
id
dot,
trace
flags.
J
The
reason
the
reason
I
said
you
you
reference
more
memory
and
if
that
happens,
asynchronously
you,
you
hold
more
memory
because
of
this
than
than
just
the
span
context.
Secondly,
you
you
pass
an
object
that
allows
people
to
add
tracing
events
or
things
that,
essentially
you
don't
want
that.
It's
a
separation
of
concerns-
you
you
just
want
them
to
see
that
the
id
you
don't
want
them
to
be
able
to
say
set
attributes
from
the
other
side.
G
It
makes
sense
we
just
don't
have
that
use
case,
so
it
seems
like
yeah.
I'm
I'm
not
convinced
that
that
use
case
is.
I
haven't
seen
a
real
world
use
case
for
that,
so.
J
I
think
the
log4j2
uses
this
integration,
not
one
the
the
log4g2
puts
in
the
context
the
our
span
context
in
their
context.
G
J
I
may
be
wrong
anyway.
Let
me
finish
this,
so
one
one
idea
was
this:
the
other
one
was
even
in
metrics
when,
when
we
build
examples,
for
example,
we
need
to
to
keep
the
trace
id
span
id
and
all
these
things
as
as
part
of
the
exemplars,
and
would
be
much
easier
to
use
spam
context
that
also
the
span
context
was
the
thing
that
we
we
clearly
mentioned
to
people
hey.
This
is
what
gets
propagated
on
the
wire
nothing
else
gets
propagated
on
the
one.
J
Maybe
maybe
the
examples
that
I
gave
to
you
are
not
necessarily
useful,
but
I
want
to
make
sure
people
people
think
about
that
before
removing
things.
G
J
J
One
key
was
the
current
span
in
the
span,
and
one
key
was
for
for
remote
contact,
okay
and
the
way
how
how
it
worked
was
we
we
we
put
one
of
them
or
both
of
them
whatever
in
the
context,
we
carry
the
context
through
the
application
and
whenever
we
have
to
start
a
span,
we
first
look.
If
there
is
a
span,
if
there
is
a
span
that
becomes
my
parent,
if
there
is
no
span,
maybe
it's
a
remote
context,
and
that
becomes
my
pattern.
J
G
J
The
propagated
span
is
still
a
span
because
we
didn't
want
to
expose
people
two
ways
in
the
context
to
think
about
two
things.
In
the
context,
there
is
only
one
thing
which
is
the
span:
if
it's
a
real
implementation
or
is
a
propagation
only
it's
it's
still
a
span
from
from
them.
It's
just
only
one
interface
one
only
object
in
the
context.
That
was
the
simplification
that
we
wanted
with
that.
G
Sure
it
felt
like
the
the
original,
like
the
at
least
the
main
point
of
the
use
case
of
span
context
or
the
image
I
had
was.
This
is
what
comes
over
the
wire.
So
this
is
what
you
know
we
have
so
now
sort
of
conceptually.
G
I
find
it
more
natural
to
think
of
that
as
a
propagated
span
coming
over
the
wire.
J
Yeah,
so
that's
that's.
The
second
use
case
that
I
have
in
mind
so
indeed
the
first
use
case
is
now
less
more
or
less
important
because
of
the
propagator
span,
but
the
second
use
case
is
still
there.
Do
we
need?
Do
we
care
about
that?
If
we
don't
care
about
that,
I
don't
have
any
objection
because
then,
really,
there
is
no
point
of
having
the
spam
context.
G
J
J
I
think
we
are
over
time
a
bit
too
much
and
I
need
really
to
run
in
one
minute,
but
anyway,
I
would
like
you
to
trust
and
maybe
point
to
anurag
as
well
think
about
the
whole
picture
and
the,
and
if
this
is
the
the
decision,
it's
fine.
G
Okay,
so
I
can
chat
with
anarag
later
today,
so
the
basically
the
do
you
want
a
pr
that
room
that,
basically,
because
you
don't
want
the
pr
that
he
did
currently
you
want.
Do
you
want
a
pr?
Would
that
help
to
move
this
forward?
What
would
be
the
best.
J
I
think
the
best
way
would
be
to
to
push
on
the
specs
issue,
and
maybe
maybe
we
should
just
put
that
as
required
for
ga
and
take
it
from
there.
G
Okay,
so
in
the
issues
create
a
new
because
I
don't
think
we
have
an
issue
for
removing
span
context,
because
I
think
we
thought
that
wouldn't
happen,
but
we
can
create
one
and
dock
in
that
issue.
Get
that
going
correct.
Okay,
yeah
thanks
for
taking
the
time.