►
From YouTube: 2020-12-03 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
C
Really
more,
I
can't
wait
until
kovitt
is
over
and
we
can
go
back
and
get
some
good
ramen
downtown.
D
F
Yeah,
I
always
talked
about
that
open
telemetry
meetup
as
well
it'd
be
really
cool.
If
the
entirety
of
like
us
could
go
to
san
francisco.
People
come
up
here
too,
so
yeah.
A
But
anyways
I
have
been
looking
over
the
the
latest
set
of
of
feedback
here.
I
wish
we
had
david
ashpole.
I
should
poke
him
because
he's
putting
a
lot
of
good
comments
into.
A
People
are
thinking
in
the
comments,
some
people,
I
get
the
impression
they're
thinking,
either
we're
talking
about
versioning
all
the
languages
together
in
lockstep,
or
that
we're
trying
to
tie
the
trying
to
tie
like
the
spec
version
to
the
other
versions.
So
I
think
I
need
to
we
need
to
add
something
that
makes
that
spells
that
out
super
clearly
right
at
the
top.
C
Yeah
there
was
another,
also
a
question
from
daniel
about
instrumentation
libraries
versus
core
api
sdk
libraries.
A
Yes,
that's
so
things
I
want
to
talk
about
today
are
yeah.
What
kind
of
guarantees
do
we
want
to
say
around
public
interfaces
that
are
not
api?
A
So
that's
you
know
the
sdk
interfaces,
but
also
the
the
contrib
stuff,
because
the
degree
which
that's
actually
the
surface
area
that
people
are
interacting
with
in
some
languages
is
more
that
stuff
when
they're,
starting
up
than
like
internal
interfaces
within
the
sdk.
C
There's
another
another
piece
which
is
instrumentation
apis
exposed
by
like,
for
example,
the
agent
the
java
agent
code
base
and
the
java
instrumentation
repo,
like
they
have
a
whole
other
set
of
instrumentation
apis,
that
there
could
be
other
guaran.
There
should
be
other
guarantees
about.
A
A
The
other
option
is
we
just
get
super
strict
about
it
and
we
say,
like
don't
break
these
things.
Same
rules
apply
to
these
interfaces
as
applied
to
the
instrumentation
api
package,
but
I
don't
know,
does
it
seem
reasonable
to
say
we
can't
break
those
apis,
we
can
only
deprecate
them
and
create
alternative
apis
and
then
remove
the
old
ones.
Following
a
deprecation
strategy.
C
So
I
feel
like
at
some
point
I
need
to.
I
need
to
go
into
a
rich
hickey
rant
about
never
removing
an
api
ever.
A
Right
or
nev
yeah
I
mean,
ideally,
we
never
remove
these
old
things
yeah.
The
only
reason
I
I
would
ever
advocate
for
removing
something
old
honestly
is,
if
we
finally,
in
the
future,
get
to
some
point
where
we
want
to
do
something
so
radically
different.
We
have
so
much
evidence
that
this
will
be
so
better
because
the
world
has
changed
in
five
years
that,
like
it's,
a
real
burden
to
maintain
all
this
old
stuff,
because
it
really
hyper
defines
how
these
things
can
actually
work.
A
Exactly
I
think,
we're
just
like
the
point
of
this
project.
Is
it's
stable
right?
That's,
like
the
the
main
guarantee
once
we
get
past
1.0
is
like
bake
this
in
we
swear
we're
not
going
to
break
it,
which
kind
of
says
getting
back
to
this
policy
around
like
deprecation
and
removal,
we're
being
asked
to
put
like
some
kind
of
date
or
timeline
on
that.
A
I
don't
know
if
we
should,
but
I
do
think
we
want
to
be
concrete
about
saying
like
this
is
the
stuff
is
here
to
stay,
so
it
could
be
like
things
can
only
be
removed
like
three
two
or
three
years
after
they've
been
deprecated
as
a
rule,
I
just
struggle
to
pick
a
number
if
we're
going
to
pick
a
number,
because
I
feel
like
I'm
just
picking
an
arbitrary
number.
C
A
I
don't
know
that
there's
a
great
answer
here,
but
I
think
it
means,
but
I
do
think
we
have
to
to
put
something
in
here
either
saying
like
we.
The
strongest
thing
we
can
say
is
we
have
no
plans
to
remove
deprecated
apis
would
be
the
strongest
thing
to
say.
Deprecated
apis
can
be
removed
in
a
major
version
bump,
but
we
have
no
plans
currently
to
do
that.
A
So
be
punt,
but
we
pump
with
like
a
very
strong
guarantee
which
says
like
you
can't
you
just
can't
remove
dedicated
stuff.
Once
you
hit
one
point
out
without
a
big
discussion.
A
Exactly
like
we,
we
will
say
that
we
have
a
deprecation
policy.
We
do
not
yet
have
a
removal
policy.
The
plan
is
to
not
remove
things
in
the
future.
We
may
come
up
with
a
removal
policy
if
we
need
one
and
spread
it
widely
and
just
leave
it
at
that.
For
now.
I
think
that
would
clearly
communicate
to
the
cigs
that
you
know
this
stuff
is
around
forever.
So
don't
don't
don't
treat
it
any
other
way.
F
A
A
A
Anyways
yeah,
so
I
I
think,
let's
let's
maybe
move
on
from
this.
If
people
don't
have
any
objection,
I'm
just
gonna
reword
this
to
say:
there's
no
removal
plans
at
this
point,
just
deprecate
things
and
you
can't
deprecate
something
until
you
replace
it
and
that's
that
yeah
yeah,
that
that
helps
a
lot
so.
C
I
have
a
meta
meta
comment,
just
while
we're
here
and
while
it's
in
the
top
of
my
head-
and
that
is
I
I
feel
like
I
know-
I'm
feeling
this
like
definitely
gun
shy
about
releasing
anything
right
now.
Oh
my
god
and
I'm
pretty
sure,
a
lot
of
maintainers
are
also
feeling
the
same
way
yeah,
especially
because
we
just
barely
stabilized,
and
I
mean
I
don't
even
I
don't,
I
can't
even
say
we're
done,
but
we're
barely
stabilizing
the
tracing
api
specification
and
etc.
A
C
A
It
it
really
seems
like
it
really
seems
like
there's
a
catch-22
here
around.
We
want
broad
adoption
of
this
thing,
but
there's
a
lot
of
hanging
back
until
we
slap
a
1.0
on
it
to
get
that
broad
adoption,
and
there
is
some
middle
ground
where
we
could
say
1.0
we're
stablish,
but
we
guarantee
nothing.
So
don't
bake
this
into
your
thing.
Right
like
it,
it
seems
like
the
classic
catch-22
there.
A
I
don't
know
how
to
solve
that
other
than
potentially
we
push
back
on
this
external
pressure
and
say:
look.
We
have
deadlines
that
are
things
we
use
internally
for
the
project
to
try
to
keep
us
on
some
kind
of
schedule,
because
we
don't
pick
targets
like
we
actually
move
slower,
but
when
companies
and
outside
groups
like
look
at
those
internal
deadlines
and
interpret
them
as
like
hard
release
states,
that's
that's
not
something
we
necessarily
abide
by,
but
we've
certainly
been
mixing
our
messaging
around
that
stuff.
C
But-
and
I
also
was
actually
thinking
about
the
other
direction,
which
is
let's,
let's
do
some
maintainer
coaching
about
the
perfect-
is
the
enemy,
the
good
and
we're
going
to
release
with
mistakes
like
there's
no
way
around
it
code
has
bugs
code
has
problems.
Yeah,
oh
api
will
be
perfect
and
at
some
point
we're
just
going
to
have
to
say
it's
good
enough
and
we're
going
to
move
forward.
Yeah.
A
And
it
just
means
from
that
point
onwards,
we
can
change
things
which
have
to
be
very
circumspect
right,
so
we'll
slow
things
will
have
to
become
more
thoughtful.
We
will
have
to
actually
what
you
mentioned
like.
We
almost
need
to
have
like
yeah,
a
maintenance
retreat
or
something
where
we
discuss
as
a
group
shifting
our
our
frame
of
mind
around
this
stuff.
G
You
know
on
that
on
that
topic,
right,
quick,
like
by
the
way
hi
hi
guys
I
have
met.
I
know
some
of
you
but
ted.
My
name
is
eric
thanks
for
responding
the
other
day
to
my,
you
know,
question
and
get
her
there,
so
I'm
from
I'm
from
new
relic
and
I'm
a
product
manager,
and
so
you
know,
obviously
I'm
I'm
interested
more
in
you
know
the
high
level
stuff
in
terms
of
deadlines
and
all
that
sort
of
stuff
and
kind
of
release
dates.
G
But
you
know,
and
specifically
I've
actually
been
working,
one
of
those
things
I've
been
working
with
it's
a.net,
sig
and
obviously
they're
on
the
sdk
side
of
things,
they're
they're,
they're
kind
of
pushing
for
you
know
ga
sooner
rather
than
later,
and
I
just
wanted
to
like
clarify
one
more
thing
and
just
in
terms
of
like
you
know,
overall
messaging
and
stuff,
is
there
an
an
intent
for
open
telemetry
in
general
to
have
an
an
announcement
saying
tracing
is,
is
ga
and
then
like
it's
kind
of
like
up
to
the
individual
language
community,
so
announce
their
individual
ga
or
is
that
you
know
is
what
like?
G
H
A
So
down
here
expected
timeline.
There
are
no
dates
on
this.
We
can
revise
this,
but
freezy
ap.
We
freeze
the
spec.
A
A
So
there's
no
one
moment
called
open,
telemetry.
Ga,
that's
something
you
can
tie
specifically
to
one
of
these
things.
We
were
thinking
of
making
some
kind
of
open,
telemetry,
ga
giant
announcement
when
we
had
tracing
and
metrics
specked
out
and
like
say,
four
major
languages
having
an
implementation
of
it.
So
the
term
ga
is
actually
removed
from
this
whole
document
right.
That's
almost
just
like
a
a
marketing
term
that
we're
going
to
use
once.
A
Actually,
I
think
I
have
a
section
here-
open,
telemetry
ga,
so
I
can
flush
this
out,
but
but
yeah.
Basically,
the
term
ga
is
is
essentially
a
marketing
term
that
we
plan
to
use
to
flag
to
just
make
some
waves
about
the
project
at
some
point
when
it
feels
good,
you
can't
really
tie
it
to
anything
specific
other
than
that
honestly.
G
Okay,
but
that
that
makes
that
makes
sense
to
me,
though,
but
I
mean
I
guess
to
end
just
to
clarify
then
before
we
get
to
that,
at
least
at
this
point,
we're
looking
at
you
know
having
1.0
versions
for
the
individual
languages,
specifically
for
just
supporting
traces
there
right.
So
so
we
would
expect
kind
of
in
the
short
term.
G
You
know,
depending
on
language
community,
that
they'll
come
out
with
those
1.0
releases
and
then
at
some
point
later
down
the
line
when
we
have
metrics
supported
as
well
too
and,
like
you
said
this
critical
mass,
then
there
may
be
like
a
larger
announcement,
saying
more
from
the
kind
of
the
marketing
side
saying:
okay,
we're
ga.
Now,
okay,.
A
A
Just
retool
some
of
this
thinking
because
we
thought
we
were
going
to
do
it,
but
actually
this
is
something
like
a
steady
drum
beat
of
like
one
perspective,
1.0
1.0,
unstable,
hey,
java,
1.0,
stable
tracing.
I
don't
want
one
more,
just
like
a
bunch
of
smaller
drum
beats
and
then
we'll
put
a
capstone
on
it
when
we
get
metrics
done
and
we
retire
open
census
and
open
tracing
permanently,
but
yeah.
That's
just
like
honestly.
Almost
I
wouldn't
say:
that's
just
a
marketing
thing.
A
No
problem
so
getting
back
into
this
doc,
I
do
want
to
figure
out.
A
A
Ability
we're
going
to
stability
guarantees
now
and
then
I
was
thinking
we
could
take
this
and
maybe,
as
part
of
turning
this
into
an
otep
or
turning
this
into
spec
language,
maybe
trying
to
massage
this
into
such
a
shape
that
what
language
what
cigs
can
do
is
they
can
take
the
cross
language
version
of
this
copy
it
and
then
adjust
it
to
fill
in
the
the
details
of
specifically
what
it
means
for
that
language.
So
every
every
language
has
their
own
copy
of
of
this
versioning
document.
A
F
At
the
end
of
the
day
where
we're
saying
like
we
need
to
probably
have
some
like
project
level
goals
like
you
know
what
v1
is
and
like
that
kind
of
stuff
that
we've
already
included
here,
but
then
yeah,
then
the
specifics
of
how
that's
implemented
or
probably
should
they
probably
should
be
kept
in
the
language
stakes
themselves.
Yeah.
A
I
just
would
want
it
might
be
better
to
keep
it
in
spec,
but
the
only
thing
about
writing
those
is,
it
would
be
great
to
have
like
each
sig
like
make
a
pr
or
something
that
proposes
it,
and
then
you
have
to
get
like
tc
sign
off
or
something
like
that.
Just
to
make
sure
you
know
we
another
way
of
saying
is
like
we
should
work
with
every
language
sig
as
they
approach
this
to
to
help
them
crack.
A
F
A
A
A
A
Just
want
to
review
some
of
these
questions
and
concerns
you
were
going
over
looks
like
we
got
some
more
in
here
from
andrew.
These
were
the
things
that
came
up
yesterday.
A
A
It
seems
like
we
just
really
don't
want
to
do
that,
hopefully,
that
there
is
a
in
these
implementation
examples
there's
a
way
to
get
around
that
I
noticed
and
go.
You
did
come
up
with
a
no
experimental
directory
tyler.
Are
you
like
satisfied
with
this?
No.
F
But
I
we
have
the
ghost
this
afternoon.
I
was
hoping
to
get
some
more
feedback
on
that:
okay,
great
yeah,.
A
Let's
I
would
like
to
just
say
that,
like
let's
not
do
that
and
really
really
try
hard
to
avoid
that,
because
I
I
do
think
that
will
create
a
lot
of
churn.
You
know
that's
like
a
python
three
move.
You
just
want
to
avoid
that.
A
The
turn
that
I
see
being
created
is
if,
when
something
goes
from,
it's
like
the
release
candidate
version
of
like
the
experimental
thing
to
being
the
stable
thing.
If
that
causes
packages
to
move
and
everyone
to
break
or
something
like
that,
then
you'll
end
up
with
either
a
bunch
of
super
frustrated
users
like
I
don't
you
might
be
happy
with
us.
We'd
do
that
or
you'd
be
stuck
maintaining
that
experimental
package
in
perpetuity
right
like
yeah.
These
are
really
the
only
two
options
there.
If
we
take
that
route.
F
Yeah,
that's
kind
of
what
I
was
seeing
when
I
was
explaining
like
I
was
going
through
those
examples
I
was
like
yeah.
This
could
kind
of
cause
that
exact
problem
and.
A
So
it's
a
language
specific
thing
here,
but
I
think
the
rule
is
like
when
you
go
from
experimental
disable
you
can't
you
can't
break
the
people
who
were
using
the
latest
spirit.
The
release
candidate,
essentially.
A
Well,
rc,
to
my
mind
I
mean
we're
just
saying,
experimental
and
stable
here
within
experimental.
Maybe
we
should
write
this
down
too.
I
was
imagining
you
go
alpha
beta
release,
candidate,
right
and
then
stable.
This
depends
on
how
languages
work
like
some
languages.
Yes,
they
go
like
1.0,
rc1
and
other
places.
You
go
0.9
rc1.
I
prefer
the
0.9
rc1
or
if
we're
going
to
do,
1.0
rc1,
it
still
doesn't
have
the
doesn't.
Have
the
stability
guarantee
until
you
get
past
that
release
candidate
right.
J
A
You
know
you
can
add
things
to
them,
but
if
something's
going
to
be
experimental,
then
yeah
you
have
to
put
that
thing
in
another
package
and
that's
where
we'll
end
up
having
to
live.
J
B
F
Yeah,
I
okay.
I
don't
think
that
was
the
example
we
were
intending,
though,
like
I
don't
think
it
was
like
you
take
something
that
from
a
package,
that's
already
released
is
stable,
and
then
you
want
to
add
an
experimental
feature
to
that.
I
think
it
was
more
just
like
you
want
to
add
metrics
or
you
want
to
add
logs
yeah.
It's
like
its
own
package.
Okay,.
A
System
yeah,
so
the
way
this
can
work
is
for
experimental.
We
we're
moving
towards
this
pattern
of
there's
some
kind
of
global
api
object.
That
seems
in
almost
every
language
to
be
really
convenient
to
people,
so
maybe
the
the
way
forward
here
is
yes,
something
experimental
is
developed
in
its
own
package
and
you
can
use
it
by
accessing
it
directly.
A
A
So
when
something
becomes
stable,
part
of
that
is,
it
gets
added
to
that
global
api
package
that
that
people
are
using.
So
it's
exp,
it
doesn't
move,
it
stays
in
its
own
package,
but
then
it
becomes
part
of
the
general
api
when
it
becomes
stable.
A
J
A
Yeah
it
you
can
break
people
in
beta
and
to
be
clear,
it's
not
the
you
can't
move
it.
I
don't
care
about
that.
It's
the
having
like
a
hard
break
right
when
you
go
to
stable,
that
will
backfire
like
that
will
just
backfire.
I'm
telling
you
right
now.
A
J
A
Are
breaking
remember
when
spring
got
on
the
horn
and
got
really
growly
about
open
tracing,
not
being
stable?
It's
because
we
did
exactly
that.
We
had
to
make
a
breaking
change
at
one
point,
to
deal
with
scope
management,
to
move
away
from
reference
counting
and
when
we
did
that
we
offered
people
complete
backwards,
compatibility
through
a
shim
carlos
put
this
together.
All
you
do
is
change
your
import
path
and
the
the
old
api
completely
still
works,
but
but
wait
wait
and
everyone.
J
J
Dot
label
on
the
whole
thing.
Okay,
my
point
is:
if
then,
then,
let's
let
me
not
get
started,
then
why
are
you
incubating
open
tracing
in
cncf
if
you
are
zero
like
not?
Let's
not,
let's
not
talk
about
that
and
I
think
I
think
your
example
is
not
the
the
right
example
in
this
discussion,
but
doesn't
matter
this.
I
think
I
think
the
document
looks
good
so.
A
A
A
What
I
wrote
this
up
above
we've
got
to
figure
out
our
guarantees
for
sdk
and
ap
and
plugins.
A
Let's
maybe
figure
that
out
and
then
after
that
I
think
the
final
question
we
have
is
we've
thought
about
how
to
have
separate
ways
to
separate
out
signals
for
the
api
packages,
but
we
haven't
thought
about
it
super
clearly
for
the
sdk
packages.
A
A
But
let's
talk
about
the
guarantees,
we
want
to
say
that
the
stuff,
the
end
user
touches
in
these
packages
doesn't
break
so
the
end
user
doesn't
get
broken.
A
So
the
end
user
doesn't
get
broken.
We
also
want
to
say
that
we
don't
care
about.
Abi
compatibility
was
the
thing
I
heard
before.
We
expect
for
this
stuff
that
people
are
recompiling.
I
don't
know
if
that's
true.
A
So
this
is
something
we
realistically
want
to
offer.
It
seems
like
we
aren't
really
set
up
to
offer
this,
so
I
wouldn't
want
to.
Unless
this
is
maybe
going
to
be
like
a
java
specific
thing.
E
A
So
so
how?
What
did
you
have
to
do
specifically
around
the
sdk
and
plug-ins
for
ensuring
that
you
don't
break
end
users
and
being
able
to
add
experimental
stuff
later
later,
we've.
A
So
the
answer
there
is
like,
and
the
interface
you're
talking
about-
are
essentially
constructors
right,
constructors
and
configurations.
E
A
I
mean
there's
other
benefits
to
this,
which
is,
if
you
tell
people
like
all
plugins,
are
configured
the
same
way,
for
example,
that
that's
actually
very
helpful
one
of
the
hard
things
about
automating.
A
lot
of
this
stuff
is
the
plugins
end
up
in
these
frameworky
things,
end
up
being
all
these
bespoke
things
and
there's
no
way
to
just
take
a
yaml
file
and
turn
it
into
like
configuration
for
a
bunch
of
plug-ins
without
doing
a
bunch
of
like
plug-in
by
plug-in
specific
work.
A
E
A
A
We
could
also-
I
could
say
we-
we
could
also
add
stability
to
these
things
separately,
so
we
could
offer
stability
for
the
api
and
offer
stability
for
the
sdk
and
offer
stability
for
contrib.
J
A
If
you
remove
a
span
attribute
right,
so
that's
the
the
conventions
right.
A
If
you're
saying
what
changed
was
not
that
it
was
not
the
api
or
it,
what
changed
was
the
data
that
was
produced
right
like
what
it
that's
like
an
important
question.
If
we
are
every
version
of
something
in
con,
a
piece
of
instrumentation
is
stable
from
the
configuration
perspective,
but
every
time
you
bump
it
produces
different
data
and
it
breaks
all
of
your
alerts
and
things
like
that,
yeah
that
that
sucks
seems
like
something
we
have
to
think
about.
A
I
worry
about
putting
a
hard
guarantee
on
that,
but
let's
just
call
that.
J
A
A
I
mean
you
can
do
this
in
various
ways
right
like
if
you
decide
these
conventions
suck
or
we
want
all
new
ones.
It's
essentially
like
a
different
version
of
that
plug-in
like
thinking
about
these
things
as
immutable
can
help
right.
So
you
want
a
v2
of
mongodb,
then
you
make
a
v2
mongodb
instrumentation,
but
you
don't
up
the
people
who
are
using
the
v1
mongodb
instrumentation.
J
So
wait
a
second,
you
are
thinking
only
about
semantic
conventions,
but
there
will
be
people
adding
their
random
stuff
there,
which
is
not
based
on
semantic
convention,
which
is
just.
I
believe
this
is
a
useful
information.
Yeah,
it's
not
gonna,
go
to
whatever
thing.
Still
that
information
exists
in
the
in
the
instrumentation
data
and
somebody
comes
and
fix.
Oh,
I
didn't
like
how
this
sound
like.
Let
me
change
a
bit
the
name
right.
A
One
thing
people
have
been
asking
about
is
like:
should
all
that
stuff
be
conventions
like
like
we're
still
generally
talking
about
like
spring
specific
things,
right
or
mongodb,
specific
things,
and
should
those
be
in
the
conventions?
But
I
see
your
point:
there's
still
going
to
just
be
stuff
in
here
that
aren't
conventions,
and
so
the
policies
should
just
be
focused
on,
for
example,
if
you
change,
which
spans
are
being
created
right,
that's
going
to
potentially
or
you
change
the
operation
name
of
a
span.
A
Well,
I
imagine
that
would
break
people's
alerts
and
dashboards
right
like
if
you're,
alerting
on
operation,
foo
and
then
foo
is
changed
to
bar
in
the
next
version,
and
you
upgrade
like
what
happens
to
your
dashboard.
I
mean.
J
A
Oh
for
sure
I
want
to,
I
want
to
specify
this
is
just
for
the
things
that
we
are
maintaining
in
core
third-party
stuff
that
ends
up
in
the
registry.
Yeah
use
that
at
your
own
risk
we
can
point
people
to
like
here
are
our
standards.
You
should
adhere
to
them,
but
we
can
only
control
our
own
stuff,
but
the
stuff,
we're
gonna,
we're
baselining
in
this
project
is
like
the
important
stuff
that
right
like.
That's,
that's
why
we
want
to
maintain
these
things,
and
so
for
us.
A
We
need
to
have
rules
about
making
that
stable.
J
Okay
is
is
that
import
is
that
right
now
in
goal
of
this
one,
zero.
A
So
we
could
stagger
these
and
that
might
that
might
be
helpful
for
maintainers
to
not
feel
like
it's
this
monolithic
thing.
They
have
to
think
about.
G
A
Yeah,
but
I
think
this
these
are
things
that
we
have
to
write
down
and
make
explicit,
because
we're
just
talking
about
here.
So
what
do
we
want
to
call
this.
A
C
I
A
Done
and
I
think
most
people
most
people
most
maintainers
are
thinking
that
way.
I
suspect
the
api
part's
not
the
big
problem,
because
we
messaged
that
it's
when
we
tell
people-
oh,
the
sdk
and
contrib
have
to
be
stable.
That's
when
maintainers
can
be
like
they
do
so.
Something
like
this
would
be
helpful
right
say
like
look
just
get
the
api
stable,
get
that
out
the
door
and
then
work
back
in
these
other
guarantees.
A
A
The
the
thing
I
think
we
we've
moved
through
all
the
questions
and
comments
that
we
brought
up
last
time
directly
factoring
the
sdk
to
handle
both.
I
feel
like
that's
just
the
same.
That's
like
on
a
language
by
language
thing.
I
don't
know
what
we
can
say
here.
That
would
be
different
than
what
we
say
on
the
api,
but
one
question
I
have
about
this
is:
can
if
the
sdk
contains
links
to
experimental
things
right,
like
let's
say
you
have
experimental
metrics
in
the
sdk.
A
Is
that
a
problem
from
a
stability
standpoint?
If
no
one
is
using
the
metrics
api,
it
basically
means
like.
If
we
don't
need
abi
guarantees
for
the
sdk,
it
seems
like
it's
potentially
not
a
huge
deal
to
have
experimental
stuff
in
there
so
long
as
it
is
only
engaged
when
the
experimental
api
is
used.
F
This
is
kind
of
interesting
because
I've
noticed
that,
like
we
do
talk
about
the
sdk
as
a
thing
in
go,
it's
kind
of
it's
a
collection
of
packages
similar
to
the
api.
Is
that
not
the
case
in
many
other
languages?.
A
We
haven't
had
strict
rules
about
how
people
factor
it
out
so
yeah.
It
makes
logical
sense
right
because
you
have
these
different
providers
right,
like
the
api,
the
interface
for
the
sdk,
you
know
and
the
shape
of
it
implies.
You
should
do
that,
but
I
have
wondered
about
under
the
hood:
will
these
things
start
getting
braided
together
more?
We
haven't
really
gotten
into
that.
Yet.
D
A
There
is
like
a
future
where
you
know:
metrics
are
interested
in
baggage
too,
and
metrics
are
maybe
interested
in
some
of
the
stuff
tracing
is
doing
and
so
on
and
so
forth.
So
I've
wondered
to
what
degree
this
stuff
starts
to
get
braided
together
under
the
hood.
At
some
point,.
E
I
mean
that's,
not
necessarily
a
problem.
If
you
have,
if
metrics
is
interested
in
baggage,
for
instance,
it
should
call
it
through
the
public
api
right
and
if
there's
separate
packages
that
should
still
work
yeah,
where
we
would
get
really
in
trouble
is
if
we
started
calling,
you
know,
sdk
only
sdk,
specific
methods.
E
I
think
we
should
avoid
that,
essentially
at
all
costs.
Well,.
C
Well,
maybe
not
baggage
in
particular,
but
if
they
want
to
get
something
out
of
the
current
span.
For
example,
if
we
want
like
ted,
is
saying,
if
we
do
want
to
have
some
more
intertwining
to
generate
auto,
auto,
generate
metric
labels
out
of
span
attributes,
for
example,
you're
going
to
have
to
be
able
to
read
them
in
some
way.
E
Yeah,
so
I
guess,
let
me
give
you
my
context
here.
In
js
we
have
very
aggressively
split
the
sdk
into
separate
packages.
We
have
one
for
tracing,
we
have
one
for
metrics.
We
have
one
for
context.
We
have
one
for
each
context,
manager
because
context
is
managed
separately,
different
methods
in
the
web
and
in
node
and
even
across
different
versions
of.
A
E
E
That's
one
of
our
one
of
the
most
frequent
questions
that
we
get
in
getter
is.
How
do
I
depend
on
just
this
component
without
pulling
in
anything
else,
so
there's
more
from
our
users
we're
getting
more
push
to
allow
them
to
depend
on
smaller
and
smaller
parts
of
it,
as
opposed
to
give
me
one
package
that
I
can
just.
J
Deploy
and
what
what
guarantees
so,
for
example,
I
asked
the
same
question
for
java
in
java,
there
is
an
sdk
common
package.
What
guarantees
are
you
offering
for
that
package.
E
We
we
call
that
core
in
in
javascript,
at
least
in
our
in
our
repository.
We
version
everything
in
lockstep.
So
if
anything
is
updated
in
the
core,
all
components
are
version
bumped
that
includes
all
api
components,
all
sdk
components
they
all
share.
The
same
version
number.
J
J
A
Yeah,
I
I
think
it's
fine
to
try
to
keep
these
things
as
separate
verticals.
I
just
wonder
that
that
would
basically
mean
like
when
the
metrics
wants
to
get
span
stuff.
It
just
registers
the
span
processor,
but
you
know
what,
if
like,
wants
to
get
span
data
with
a
spam
processor
and
then
the
tracing
wants
to
attach
metrics
labels
to
spans,
and
so
it
gets
some
metrics.
But
you
could
end
up
with
weird
stuff.
J
J
J
So
example,
this
example
in
in
a
language
like
java,
okay,
matrix
metrics
sdk,
wants
to
install
a
processor,
a
spam
processor
in
the
trace,
sdk
for
capturing
or
building
more
metrics,
or
whatever
reasons
it's
not
possible.
If
you
have
them
independent
and
not
depending
on
each
other,
which
me
that's,
why
you
have
them
independent
then.
Hence
you
have
a
problem.
You
cannot
install
that.
A
You
could
have
dependencies
go
from
stable
to
from
you
know,
experimental
disabled
packages,
so
the
metrics
package
could
depend
on.
You
know
the
tracing
package,
but
not
vice
versa,
but
I
agree
in
general,
you
end
up
with
some
kind
of
loop
right,
you'll
end
up
with
a
circular
dependency
of
some
kind.
J
So
no
no,
the
problem
is,
the
problem
is
the
reason
why
you
want
to
have
them
in
separate
package
is
to
one
is
because
you
want
to
to
reduce
the
size
of
the
the
thing,
but
if
you
take
a
dependency,
even
though
a
stable,
unstable
forget
about
stabilization,
both
are
stable
and
if
you
get
a
dependency
from
one
to
each
other,
you
lose
the
entire
benefit
of
having
them
in
separate
packages
yeah.
What
is
the
point
of
having
them
in
separate
package
if
you
end
up
with
a
dependency
between
them.
A
Yeah,
that's
we.
We
haven't
told
people
explicitly
that
it's
a
high-level
goal
to
allow
people
to
only
install
one
portion
of
the
sdk
and
not
another
portion
of
it.
Okay,
we
some
languages
are
doing
that,
but
that
that
seems
like
maybe
a
thing
we
do
have
to
take
a
hard
look
at.
It
seems
it's
not
something.
I
want
to
bake
into
our
guarantees
right
now.
I
think
I
just
want
to
say
in
our
guarantees
we
just
it's
more
just
about
the
public
surface
area
of
the
sdk.
A
And
I
don't
quite
know
how
to
write
that
it
doesn't
sound
like
we
need
abi
guarantee,
that's
actually
the
the
question
I
have
for,
like
maybe
java
and
other
languages.
Does
the
sdk
need
to
be
abi
stable.
It
seems
like
no,
I
see
bogdan
shaking
his
head.
J
I
think
we
can.
We
can
ask
our
so
this
artifact
is
used
by
only
the
final
user
he's
not
going
to
come
via
a
transitive
dependency,
because
that's
how
we
intend
them
to
to
be
used
and
that's
why
we
have
an
sdk.
So
and
as
long
as
it's
not
a
transitive
dependency,
you
will
end
up
being
compiled.
So
you
don't
need
abi
compatibility
because,
because
is
the
final
app
that
builds
the
jar
which
includes
these
new
these
dependencies
these
dependencies.
J
A
A
Not
outside
of
just
the
application
in
it,
no
right.
A
I
mean,
I
hope
so
right
like
that's.
We
have
to
make
some
clear
rules
about
that,
but
that's
I
mean
I
have
a
blog
post
coming
at
some
point.
That's
like
yeah.
Anyone
like
how
do
people
fork
open,
telemetry
and
one
way
you
do
it.
Is
you
install
a
bunch
of
extensions
on
the
back
end
that
have
a
bunch
of
apis?
You
need
to
use
on
the
front
end
and
now
you're
using
some
other
api.
That's
not
open,
telemetry's
api.
A
I
don't
think
people
should
write
those
personally,
like
I
mean
maybe
it's
some
weird
experimental
thing.
Maybe
people
are
gonna,
do
it,
but
nothing
that
we
give
people
that
we
give.
People
should
work
that
way.
I
A
I
can't
control
what
some
other
guy
on
the
internet
does
with
this
stuff
and
state.
Likewise
with
the
plug-ins
I'm
really
just
talking,
rather
than
plug-ins,
I
should
say
contrib,
it's
just
this
contrib
repo
has
some
guarantees
to
it
like
we
offer
four
things
right:
api,
sdk
conventions
and
contrib,
and
we
just
need
to
explain
for
each
one
of
them
what
the
guarantees
are.
Yeah.
J
A
A
D
J
A
A
That
seems
to
me
to
be
the
only
guarantees
these
things
would
need
unless
they,
for
whatever
reason,
have
some
other
api
that
you're
touching,
but
that
smells
to
me,
I
kind
of
I
don't
think
we
have
any
plug-ins
that
you
plug
it
into
open
telemetry,
and
then
you
control
it
from
your
application,
but
it
almost
be
like
concerned
if
you
had
something
like
that,
but
if
you
end
up
with
something
like
a
control
plane
right
or
whatever
and
like
so,
you
need
to
make
an
interface
for
how
that
control,
plane,
controls
things
like
that
thing
would
have
to
be
stable.
J
A
Yeah,
okay,
so
we
want
to
just
say:
if
there
is.
A
A
Okay,
so
we're
at
we're
at
time
right
now.
I
don't
know
if
people
have
the
ability
to
to
meet
later
today
in
the
afternoon
at
all,
I
am
free,
so
I
can
make
that
happen.
A
F
My
plan
is
to
take
this
so
to
answer
that
question
directly.
No,
I
don't
think
so.
I
think
that
there's,
I
think,
there's
still
some
questions
as
to
what
we
want
to
do
in
the
go
sig
though,
and
so
I
I
wanted
to
take
this-
to
the
go
sig
and
run
by
them
and
see
what
everyone
there
thinks
just.
A
So
we'll
take
it
to
get
her
I'll,
see
you
guys
in
the
spec
channel
sounds
good
bye.
A
A
A
H
H
D
H
Oh
yes,
there
are
no,
let's
do
a
copy
paste
here
put
away.
The
third
it
looks
like
we've
got
some
of
the
same
flux
here
go
ahead
and.
H
I
H
It
just
means
we
have
no
pre-written
agenda
that
yeah.
I
I've
been
not
pushing
stuff
onto
the
agenda.
I
About
so
yeah
one,
so
one
of
the
one
of
the
use
cases
I
believe
that
he
talked
about
was.
I
What
the
thought,
those
inner
http
clients
http,
calls
that
this
issue
proposes
to
add,
as
as
events
on
like
a
upper
level
database
or
http
or
http
call
call
the
question.
No
scrap
that
more
important,
more
important
idea
that
we
talked
about.
H
So
my
understanding
at
least-
and
we
have
the
we-
have
a
spec
master
on
the
call
right
now
so
we'll
see
if
this
understanding
is
correct,
is
child's
bands
are
like
one
to
one:
child's
fans
are
outgoing
and
map
their
parent.
The
parent
of
child
span
is
a.
C
I
H
H
I
I
J
Because
for
client
server,
where,
where
we
define
these
kinds,
the
the
definition
is
it's
it's
only
for
remote
calls.
Let's
put
this
way
and
and
only
the
remote,
so
it's
used
the
client
and
server
at
least
I'm
not
wrong.
If
I'm
not
wrong,
that
was
the
intention
to
be
used
only
for
remote
calls
to
model
the
the
client
half
of
a
remote
call
and
the
server
half
of
the
remote
call.
I
I
H
I
have
a
question
bugged
in
what
about
a
jdbc
database
cause
should
those
be
client
or
internal
from
your
perspective.
J
Is
there
anything
after
that?
Is
there
any
other
span
or
you
don't
know,
we.
H
So
what
we've
done
so
far
in
the
instrumentation
repo
is
we
we
put
the
client
span
in
the
context
and
then,
if
any
time,
we're
downstream
of
that,
we
suppress
any,
do
other
client
spans
so
that
we
only
get
that
top
level
client
span.
J
I
But
that
brings
a
problem
that
you
lose
information
which
may
be
valuable
like
for,
for
example,
how
much
time
did
did
I
actually
spend
in
retrieving
connection
from
connection
pool
or
they
or
dns
look
up?
If
you
totally
hide
all
those
network
layout
details,
you
lose
them,
but
you
have
to
put
them
somewhere.
You
have
events
correct.
J
So,
essentially,
you
modeled
events
I
feel
like
people
are
not
using
the
events
too
much,
or
I
saw
that
and
people
always
think
about.
Let's
create
a
span
span
is
way
heavier
than
events,
and
also
events
are
more
more
performant.
I
Okay,
then,
for
example,
let's
take
we
have
like
project
reactor,
provides
its
own
http,
client,
http
client
from
org
project
reactor.
What
not
package
from
the
kind
of
client
perspective.
That's
total
http
client,
and
we
should
model
that
as
a
client's
path,
but
under
the
hood
it
it.
It
uses
nikki
and
we
have
instrumentation
for
native
as
well,
which
want
to
create
clients,
plans.
Okay,
it
will
see
that
there
is
already
client
spams.
J
But
okay,
if
you
know
that
the
jdbc
the
the
reactor
rapper
is
not
actually
is
just
a
rapper,
why
do
you
want
to
create
a
client
expander.
I
J
I'm
not
I'm
not
sure
I
follow,
I
does
it
matter
for
for
for
people
the
kind
of
the
span
do
you
think
it
matters
for
humans
or
it
matters
for
machines.
H
So
we
do
get
we
get
richer,
often
times
we
get
richer
info.
At
that
higher
level
like
from
the
project
reactor
http
client,
we
may
get
a
route,
a
template
that
the
developer
used,
so
we
can
get
a
better
span
name
out
of
that.
J
I
That's
why
we,
we
forbid
nasty
clients
funds.
Yes,
that's
why
you
forbid
what
nested
clients
client
spends
sure
if
native
sees
that
there
is
already
client
span,
it
will
not
create
a
new
one,
so
my
question
was:
should
it
instead
add
some
events
on
that
already
exist
in
the
blind
spot.
J
Definitely
the
events
and
everything
else
should
be
added
as
normal
things.
It's
if
you,
if
you,
if
you
don't
want
to
create
another
span,
you
just
don't
create
another
spam,
but
the
span
exists.
You
can
still
use
that
span
and
add
more
stuff
to
it.
Everything
that
you
would
have
added
anyway.
You
can
still
add
it
to
that
span.
It's
just
you
don't
create
a
new
one.
You
instead,
you
consume
a
pattern.
I
But
but
that's
the
point
I
in
without
already
existing
client
spam,
I
would
create
just
a
new
client
spam.
Okay,
it's
not
that
I
I,
I
would
already
add
some
events
and
now
I
just
add
those
events
to
already
existing
spam.
My
it
seems
like
we
have
to
like
instead
of
spam
creation,
create
some
events
and
already
existing
spans.
If
you
want
to
catch
the
same
network
level,
information.
H
I
D
J
Events,
oh
yeah,
that
that's
that's
definitely
clear
to
me
that
that's
how
we
should
do
and
like,
for
example,
you
can
have
an
event,
start
dns
resolution
and
dns
revolution,
for
example,
and
even
if
you
have
the
problem
of
another
rapper
on
top
of
your
raw
client,
I
still
believe
the
dns,
even
though
so.
If
I
do
an
http
call
to
let's
say
microsoft.com
and
the
first
thing
I'm
doing
a
dns
resolution
as
part
of
this
and
then
I'm
doing
the
real
tcp
connection
to
the
microsoft.com
ip.
J
H
Again
some
context
on
where
the
first
place
this
came
up
actually
many
months
ago,
onorag
raised
it
around
the
aws
sdk,
which
is
essentially
right
wraps
the
http
calls
and
they
wanted.
The
aws
sdk
calls
like
you,
know
the
s3,
wherever
to
be
client
spans,
because
again
they
get
richer
data
on
that
about
where
they're
calling
like
that,
it's
an
s3
service.
J
Wait
wait
but
does
it
matter
if
it's
marked
as
client
versus
as
internal
like
this
is.
This
is
where
I'm
failing
like
if
human
is
using
is
looking
at
this
data?
Does
it
matter?
If
I
see
here
a
span
with
all
this
information,
and
then
I
have
the
the
low
level
span,
that
is
marked
as
client
and
is.
Is
the
http
client
connection.
H
J
H
So,
where
it
matters
bugden
is
when
you're
drawing
the
distributed,
trace,
map
and
you're,
saying
that
this
node
here
is
talking
to
s3,
for
example,
that
map
is
all
built
based
on
the
client
server
span
relationships,
and
so
they
want
richer.
They
want
to
know
that
we're
talking
to
draw
this
note
as
s3
as
opposed
to
oh
this
ip
address.
That
is
all
that
they
have
accessible
at
the
at
the
http
client
level.
J
I
get
it,
I
get
it
to
be
honest
by
the
way.
The
the
client
and
server
would
not
create
it
for
this
purpose
and
people
start
abusing
them
in
this
way,
and
probably
that's
why
a
bunch
of,
and
hence
my
my
all,
concerns
all
the
time
that
if
you
give
something
to
users
they
they
will
find
ways
to
to
use
them
in
a
way
that
you
didn't
think.
I
J
So,
by
the
way,
there
is
a
one
thing
that
I
know
for
sure
couple
of
vendors
do,
which
is:
do
you
rely
on
the
fact
that
the
client,
the
the
parent
of
a
server
spam
is
so
or
the
parent
of
the
server
span,
has
only
one
child
that
server
span
for
for
trace
competition?
J
H
I
H
J
The
redirects
is
not
a
problem
who,
if,
if
a
redirect
happens,
correct
you,
you
see,
that
is
a
redirect.
H
Today,
our
instrumentation,
I
think
we
only
produce
one
span
if
the
the
http
library,
under
the
hood
does
the
redirect.
J
J
H
I
guess
so,
just
from
our
perspective,
we
know
all
the
instrumentation
that
we've
built
so
far
and
it
all
conforms
to
the
notion
of
you
know,
client
span,
but
it
doesn't
conform
to
the
notion
of
to
you
know
there
only
being
a
one-to-one
relationship.
H
J
H
Okay,
if
you
accept
that,
then
that's
fair
nikita,
I
was
going
to
ask
on
this
one:
is
this
a
theoretical
concern,
or
do
we
have
any
instrumentation
today?
That
needs
to
worry
about
this.
H
Propagation,
so
this
is
an
interesting
example
here,
where
it's
actually
important,
that
we
do
context
propagation
at
the
higher
level
at
the
aws
sdk
level,
because
they
sign
the
the
http
bodies
and
if
we
inject
the
header
later
in
the
yeah,
okay,
the
instrumentation
we
break,
we
break
it:
okay,
yeah,
that's
already
modeled,
more
or
less.
J
Yeah,
then,
you
cannot
even
create
a
client
spam
because
that
will
not
be
able
to
be
apparent
of
the
server
correct
the
http
you
you
create
a
mess
there.
If,
because
you,
if
you
put
the
the
parent,
the
the
w3c
con
header,
you
put
it
constructed
from
the
aws
sdk
span,
not
from
the
http
that
will
be
the
parent
of
the
next
hope
correct
of
the
remote
span.
H
J
I
think
I
think
I
I
came
up
with
the
right
definition.
The
span
that
that
is
marked
as
client
is
the
one
that
its
spam
context
is
serialized
on
the
wire.
H
H
I
I
So
we
just
currently
assume
that
we
create
a
client
span
and
we
do
context
propagation
right
away
here.
In
this
case,
it
seems
that
we
should
create
a
client
spam.
That's
the
database
call
we
don't
do
context
propagation
for
data.
These
calls,
because
we
don't
know
where
to
put
them.
There
is
no
no
wire
to
put
to,
but
then
well.
H
I
J
Why
you
already
override
the
span
correct
you
already,
you
already
have
your
own
instance
of
the
span.
Why
do
you
not
save
it
in
the
span
and
why
do
you
put
as
a
separate
thing
in
the
context.
I
H
Here
I
think
so
we
already
we
need
to
do
this
for
server
spans,
so
we
do
put
the
server
span
also
in
the
context
for
two
purposes
actually
not
even
for
not
creating
nested
server
spans
today,
but
for
being
able
to
update
the
name
the
route
on
the
server
span,
because
we
can't
guarantee
that
it's
always
going
to
be
our
direct
parent.
So
we
can't
update
the
name
on
the
parent.
J
H
Because,
like
if
we're
in
the
spring
mvc
framework-
and
we
want
to
take
the
route
from
there,
we
don't
know
if
a
user
has
inserted
an
internal
span
in.
H
I
J
I
J
J
H
Yeah,
no,
I
it's
a
good
point,
especially
around
interop,
our
interop
story
with
manual
instrumentation,
where
they
aren't
setting
that.
J
Yeah,
you
are
creating
hex
that
works
only
in
your
environment,
because
it's
not
the
normal
usage
is
not
a
normal
way.
It's
not
documented
that
people
will
will
set
this
last
client
span
if
they.
So
if
somebody
manually
creates
a
client
span
on
top
of
an
http
yeah
will
not
work
this
way
because
whatever
they
didn't
create
this
hacky
way.
J
I
K
Yes
yeah,
I
believe
so,
would
the
instrumentation
hap
is
that
implementation
added
to
the
bootstrap
class
path.
H
That
is
an
excellent,
excellent
point:
tyler!
No,
it
is
not.
H
I
I
J
A
lot
of
the
requests
that
I
heard
is
for
the
local
root
span
id
that's
what
they
need.
Why?
Because
that
identifies
the
entire
request
request.
J
It's
the
trace
id
may
come
twice
to
my
service,
because
if
somebody
hits
me
twice
a
bigger
request,
but
that
root
span
id
identifies
one
that
completion
of
trace
id
plus
that
root
span
id
defines
one
request
globally
again-
and
I
heard
this-
I
don't
know-
if
that's
the
same
case,
but
I
heard
this
use
case
and
and
if
somebody
else
will
keep
coming
to
me
I'll,
I'm
willing
to
add
it
to
the
specs,
but.
J
Okay,
one
of
the
requests
that
I
know
from
google
was
they
had
a
map
with
some
some
informations
about
that
request,
and
they
use
that
as
an
id
in
the
map,
which
was
not
the
right
thing
to
do.
Don't
get
me
started
on
that,
but
that's
why
they
did.
The
second
thing
was
people
wanted
to
to
have
logs
for
the
same
request,
even
though
we
recommend
them
to
use
panel
e3s
id.
Some
people
may
want
only
the
trace
id
span
id
from
the
root
span
because
they
believe
doesn't
matter
which
span
it
is.
J
I
want
to
be
able
to
search
for
for
for
one
thing
and
see
all
the
logs
for
that
specific
request
in
a
in
a
logging,
backend.
H
One
use
case:
I've
heard
for
this
also
just
from
our
customers
is
they
want
to
put
custom
attributes
on
the
request,
because
the
request
is
sort
of
the
piece
of
telemetry
that
they
care
about
the
most
and
look
at
the
most
and
but
depending
on.
You
know,
if
they're
below
the
spring
mvc
framework,
where
we
create
an
internal
span,
parent
is
going
to
return
that
internal
span
and
that's
where
they're
going
to
put
the
custom
attribute
which
isn't
really
where
they
want.
K
That's
when
your
dog
has
something
similar
like
we,
we
add
a
lot
of
data
to
like
that
local
root
span.
I
don't
really
like
it,
and
so
I
don't
I'm
not
encouraging
everyone
else
to
adopt
it.
Just
because
you
know
it
seems
wrong
to
me.
J
J
J
Now
now
there
is
a
good
question:
when
do
you
create
a
local
spam
or
an
internal
spam,
because
this
is
where,
where,
where
I
keep
hearing
that
there
will
be
a
lot
of
spams?
But
maybe
maybe
this
is
the
disconnect
from
at
least
from
my
mind,
which
I
don't
expect
to
be
too
many
spans.
So
I
don't
expect
to
have
10
20
spans
per
service
request.
I
expect
to
have
let's
say
one
for
the
server
one
for
every
client,
rpc
client
request,
and
maybe
at
most
one
in
the
middle.
J
H
So
the
main
one
that
we
create
today
is
for
the
mvc
framework,
so
like
the
spring
control
the
controller
method,
so
that
ends
up
being
then
the
parent
of
a
lot
of
the
cus
of
a
lot
of
the
application
logic.
So
it
gets
in
the
middle
there.
K
But
generally,
the
controller
is
what
the
customer
has
or
the
the
user
has
the
most
control
over,
but
anyway
going
can
I
just
go
back
really
quick
to
the
the
notion
of
the
their
local
root
span.
I
would
argue
that
the
better
way
to
handle
that
would
actually
be
to
have
like
a
separate,
metadata
or
payload
object,
that
additional
information
that
applies
to
the
whole
trace
can
be
added
to
not
necessarily
just
to
a
specific
span.
K
So
really
like
what
so
so
this
is
ultimately
a
problem
with
sending
spans
as
soon
as
they're
done
right,
because,
if
you're
looking
at
just
the
local
root
span
in
theory,
that
could
have
been
a
span
that
finished
before
your
current
span
actually
started
executing,
and
so
that
may
have
been
sent
already
absolutely.
K
But
if
you
have
some
sort
of
like
additional
metadata
that
you
can
send
separately
from
the
span
that
says
hey,
this
is
some
metadata.
That
applies
to
everything.
That's
not
I
mean
is
that
currently
how
people
treat
baggage
is
baggage
sent
as
a
separate
thing?
No,
I
didn't
think
so.
It's
only
propagated
forward
and
attached
to
that
spam.
K
K
Because
really
like,
if
you're
looking
at
a
a
regular
server
request,
you
might
have,
this
is
actually
interesting.
We
currently,
we
recently
ran
into
a
trace
that
a
customer
is
complaining
that
it
is
not
very
helpful
and
that's
because
the
initial
request
is
handled
by
zuul.
It's
a,
I
think.
K
It's
like
a
netflix
proxy
layer
and
the
way
it
handles
it
is
it
it's
accepting
all
requests,
it
does
some
internal
processing
and
then
it
does
a
servlet
forward
to
the
actual
url
that
it
wants
that
sent
to
and
the
way
this
results
is.
You've
got
a
top
level
trace
with
a
very
unhelpful
url
and
the
actual
useful
information
is
hidden
inside
of
that
servlet
forward,
and
we
don't
currently
have
a
good
way
of
like
promoting
something
that
deep
into
the
trace
up
to
like
be
a
top-level
useful
name.
K
So
that's
just
one
example
of
where
I
think
like.
Maybe
this
like
higher
low-level
abstraction
of
trace
metadata
would
be
potentially
useful,
but
I
don't
think
you're
looking
for
a
trace
metadata.
J
You're
looking
more
for
per
it's,
it's
a
property
is
not
the
the
root
of
the
so
so
what
I'm
trying
to
say
is,
if
you
add,
a
a
route:
okay,
an
hdb
route
somewhere.
That
applies
only
to
to
a
scope
of
the
trees,
not
the
entire
trees.
Oh
yeah,
I
I
don't
disagree
so
so
you
are
looking
more
for
for
a
scope
trace
metadata,
not
the
entire
trace,
metadata
correct.
J
The
problem,
the
problem
as
tyler
mentioned,
the
problem
with
that
is,
if
that
is
closed
or
ends,
because
you
want
to
to
send
the
response
sooner
like,
for
example,
you
get
the
request
and
you
have
set
up
like
respond
200
immediately
and
don't
wait
for
the
the
request
to
to
be
passed
to
the
downstream
level.
J
Then
that
span
most
likely
will
be
closed
and
then,
hence
you
will
not
have.
Even
if
you
call
into
the
local
span,
adds
update
name
that
will
not
have
any
effect
so.
H
H
J
I
C
26
11
or
just
you
know,
I
know
we
haven't
made
any
official
decisions
on
the
release
planning,
but
but
sounding
more
and
more
like
we'll,
be
pulling
metrics
out
of
the
public
api
for
the
first
release,
which
I
think
means
we'll
we'll
want
we'll
need
to
do
something
with
the
oshi
and
the
other
metrics
instrumentation
that
is
currently
available
via
library
instrumentation.
So
I'm
not
sure
I
just
wanted
to
bring
it
up,
because
I
don't
actually
know
what
we
should
be
doing.
But
it's
something
we
should
ponder.
H
D
C
H
Cool
thanks
so
just
quickly.
The
last
few
minutes,
our
weekly
digest
things
that
have
gone
in
this
is
cool.
The
test
matrix
were
gonna,
start
testing
against
different
lots
of
different
java
versions.
H
The
smoke
tests
against
lots
of
different
java
versions,
java
vendors
application
servers
and
a
few
different
simple-ish
use
cases
for
smoke
tests.
For
that,
for,
let's
see
oh
yeah,
we're
updated.
There's
a
lot
of
breaking
changes.
Anybody
pawel
you're
using
the
instrumentation
tracers
a
lot
more
context.
Instead
of
passing
around
spans,
there's
another
pr,
that's
probably,
I
think,
will
be
merged
today.
J
By
the
way,
one
thing
that
I
found
confusing
when
I
looked
at
the
your
code,
you
still
have
a
thing
called
tracer,
probably
inherited
from
open
tracing
and
stuff,
which
is
different
than
the
the
open
telemetry
tracer
correct.
That
was
three
weeks
a
month
ago
may
have
changed.
H
No
it's
there
and
it.
H
Open
tracing
we're
sort
of
calling
them
instrumentation
tracers,
another
name.
J
I
would
call
them
by
the
way
there
was
a
discussion
that
at
one
point
you
need
to
have
the
meter
as
well
and
other
things,
so
you
may
want
to
to
find
a
name
that
is
more
generic,
that
embeds
all
the
things
is
that
the
purpose
of
this
you
may
want
to
have
a
more
generic
name
that
will
include
support
for
baggage,
for
example,
if
people
want
to
interact
baggages
or
for
for
others.
H
It
is
the
point
to
basically
be
the
one
that,
where
most
of
the
instrumentation
logic
lives,.
D
H
Of
there
for
a
given
like
apache,
http
client.
J
Library,
then
again,
then
you're
probably
going
to
start
at
one
point,
doing
doing
baggage
work,
doing
meet
metrics
work,
doing
a
bunch
of
things
in
the
same
place,
because
you
don't
want
to
have
independent
plugins.
I
would
expect
just
the
only
thing
that
you
want
to
have
different
is
maybe
enable
disabled
parts
of
these
things,
some
boolean
or
thing
so
that
I
would
suggest
to
find
a
more
generic
name.
Instrumenter.
H
Cool
yeah,
we
are
doing
baggage
today,
but
no
metrics,
but
I
I
like
that
idea.
J
One
of
the
thing,
by
the
way
that
I
really
liked
google
in
terms
of
baggage,
is,
if
you
can,
on
the
server
side,
if
you
can
add
the
the
route
or
the
spam,
essentially
the
the
the
information
that
most
likely
you
use
for
for
the
span
name
of
the
the
the
server
span
to
be
a
baggage
called
the.
J
I
don't
know:
rpc
server,
name
or
service
service
name
or
something
like
that.
It
will
be,
and
then.
D
H
Yeah
we
we've
been,
we've
been
rejecting
or
we've
been
funneling
everybody
who
wants
like
new
instrumentation
attributes
over
to
the
spec
first.
H
Yeah
cool
this
mateosh.
What
was
this?
What
did
this
cover?
We
have
some
resource
providers
now
that
generate.
B
J
By
the
way,
there
is
an
interesting
discussion
related
to
this
in
the
collector
repo,
and
they
people
immediately
saw
that
especially
the
collector
being
written
in
gold
that
there
is
duplicate
code
in
in
goal
to
to
do
resource
detection
between
the
goal,
hotel,
library
and
us
the
collector
so
and
you
will
probably
end
up
with
duplicate
code,
but
luckily
nobody
will
say
because
it's
different
language.
So
nobody
will
point
at
this
duplicate
code
with
with
the
other
stuff.
What
I'm
trying
to
say
is
don't
try
to
go
too
much
into
the
resource
detection.
J
I
would
strongly
encourage
you
at
one
point
to
tell
users:
okay,
if
you
want
to
have
more
than
just
a
couple
of
things
like
os
process
and
stuff
use
the
collector
route,
everything
to
through
the
collector
and
the
collector
will
enhance,
with
all
the
resources
possible
in
the
world
like
informations,
about
ecs,
like
amazon,
ecs
or
or
kubernetes,
or
a
lot
of
things.
I
don't
think
you
want
to
have
all
of
them
in
java.
H
Makes
sense
yeah
I
mean
we
definitely
have
some
users
who
are
not
using
the
collector
but
agree,
but
I
agree
that
that
we
don't
want
to
do
everything.
H
All
right
we've
got
one
minute
left
so
anything
oh
yeah.
We
had
publishing
problems.
We
spent
most
of
last
week
last
week's
meeting
talking
about
them.
So
just
a
quick
update
there
on
we
anurag
is
testing
out
publishing
to
sona
type
directly.
H
H
We
have
like
over
a
thousand
artifacts
that
we
publish
or
files
and
bin
tray,
keeps
flaking
out
and
not
in
the
mid
in
the
middle
of
our
releases.
So
we
can't
make
releases.
J
In
open
senses
we
had
the
same
issues
and
one
of
the
thing
that
was
causing
us.
The
issues
was
the
parallel
builds
in
gradle,
so
whenever
we
enable
the
parallel
builds
and
parallel
pushes
of
the
artifacts
that
was
screwing
up
sonotype,
so
we
had
to
disable
for
the
for
the
just
for
the
artifact
pushes
for
the
uploads.
J
We
had
to
disable
parallel,
uploads
and
stuff
there.
That
was
a
good.