►
From YouTube: 2021-09-15 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
A
B
B
Since
we
don't
have
ted
again
because
he's
on
vacation
the
folks
from
microsoft,
johannes
well,
I
hope
he
doesn't
mind,
but
his
wife
is
delivering
a
baby.
So
he
has
an
excuse
not
to
join.
D
D
D
So
if
you
guys
can
start
adding
any
agenda
items
to
the
thought,
that's
great,
then
we
can
just
get
started.
D
B
Before
we
start
it
seems
oh,
so
the
the
monday
meeting
is
cancelled
indefinitely.
D
Yes,
so
so
I
don't
have
access
to
the
calendar
and
ted
is
was
out,
so
I
don't
think
it
got
removed
from
the
main
google
calendar.
The
shared
calendar
I
put
in
a
request
to
have
that
removed,
but
I
think
the
coverage
that
we
have
with
this
meeting
as
well
as
the
thursday
meeting
and
then
eventually,
I
think
there
was
a
request
for
an
http
meeting.
D
I
think
that's
more
than
sufficient,
and
I
think
we
discussed
last
week
that
if
we
need
another,
if
once
a
week,
is
not
enough
for
the
apac
time
zone
that
we
can
consider
adding
another
day
and
time
slot,
so
we
were
gonna
see
how
it
goes.
First,.
B
D
Okay
looks
like
lumila
you're,
the
only
one
with
some
items
here,
so
when
you're
ready,
if
you
wanna
start
with
the
first
topic,
that'd
be
great.
B
Yeah,
so
there
was
a
discussion
about
how
we
proceed
with
http
conventions
and
let
me
show
you
my
screen:
oh
or
maybe
michael,
can
you
open
it?
It's
the
first
item
on
the
agenda.
B
Yeah,
so
basically,
we
are
trying
to
like
fund
the
the
working
group
for
http
within
microsoft,
so
we
are
trying
to
drive
it
within
microsoft.
It's
nowhere
like
internal
microsoft
group
and
the
question
is
mostly:
what
is
the
process
around
it?
So
with
like
messaging
there
we
have
a
working
group
because,
probably
it's
like
all
new.
There
is
a
lot
to
discuss
and
agree
upon
with
http.
I
think
there
is
no
not
enough
consensus
and
there
were
a
couple
of
proposals.
B
The
first
one
is
to
create
a
new
group
and
meet
like.
There
are
some
proposals
of
times
here.
I
think
there
are.
There
are
a
few
folks
who
propose
to
maybe
have
normal
github
discussions
and
discuss
http
topics
on
this
meeting
and
I'm
kind
of
interested.
What
folks
here
think
about
so
ignore
it
I'm
sorry,
I
posted
it
in
the
wrong
repo,
ignore
this
scroll
down.
B
So
here
there
is
a
discussion:
how
what
what
does
the
process
for
http.
D
I
mean
I'll
leave
it
to
the
group
to
see
what
books
want
to
do.
I
know
for
like
james
and
folks
in
terms
of
time
zone.
This
is
the
only
meeting
that
kind
of
accommodates
your
time
zone.
So,
if
that
works
for,
for
you
great
and
I
guess
it
depends
on
the
depth
of
topics
we
have
for
http
at
this
point,.
E
Yeah,
I'm
I'm
happy
to
discuss
http
in
this
meeting
because
that's
relevant
to
me,
but
I'd
also
like
the
opportunity
to
discuss
other
things,
not
just
purely
http
so
but
but
like
yeah,
I'm
happy
to
to
discuss
http
here,
but
yeah
also
other
things
because,
as
I
said
like
for
me,
this
meeting
has
to
be
kind
of
broad,
because
I
can't
really
wake
up
at
4
a.m.
To
get
to
the
other
meeting,
unfortunately,
but
I'm
more
than
happy
to
discuss
htp.
E
But
would
this
be
a
specific
http
meeting?
I'd,
probably
like
it
to
be
a
bit
broader
than
that,
because
I
can't
make
it
to
all
the
meetings.
I
guess
that's
that's
my
point
of
view.
E
Were
you
looking
to
make
this
meeting
specifically
for
http
or
just
like,
adding
it
in
to
http,
adding
it
into
the
existing
discussion.
B
I
think
if,
if
we
are
going
to
have
a
scoped
work
and
http,
we
would
probably
want
to
dedicate
at
least
several
meetings
to
discuss
controversial
things,
but
I
don't
know
if
we
like
have
enough
resources
to
do
it
and
like
in
a
short
period
of
time.
Maybe
it
will
be
once
a
month
or
something
it's
it's
actually.
I
don't
know
how
how
it
can
happen.
B
D
So
my
question
is,
at
least
from
my
standpoint-
is
that
I
know
that
you
know
there
are
folks
who
are
willing
to
meet
in
the
afternoon.
I
guess
my
thought
around.
That
is
how
many
folks
we
have
in
like
in
the
eu
time
zones
that
want
to
be
part
of
that
discussion,
because
that's
gonna
be
the
biggest
scheduling
difficulty,
because
what
we
could
potentially
do
is
maybe
we
just
make
a
thursday
afternoon
meeting
or
some
other
afternoon
meeting
to
discuss
the
http.
E
B
Unfortunately,
we
don't
have
anyone
who
didn't
want
to
have
a
dedicated
meeting
for
it
today
on
this
call,
so
we
can't
advocate
for
them,
but
basically
that
I
think
sergey
and
ted
mentioned
that
they
don't
want
a
specific
meeting,
because
it's
too
much
segmentation
and
it's
hard
to
attend
all
of
them.
So
I
don't
know.
Maybe
we
we
can
leave
it,
discuss
it
offline
because
we
don't
have
okay.
D
Yeah
we
can
time
box
the
conversations
too,
though
ludmila.
I
guess
my
point
is
that
like
if
we
have
broad
enough
topics,
for
you
know
to
discuss
messaging
and
some
of
the
other
ones
or
anything
more
generic
like
maybe
we
talk
about
the
resource
cemented
conventions,
maybe
we
just
timebox
some
of
them
so
that
way,
at
least
we
can
have
the
discussion
with
the
folks
here,
but
yeah.
Why
don't
we
once
ted
comes
back?
Maybe
we
could
talk
about
it
more
and
try
to
find
an
appropriate
time
slot.
E
E
That
would
write
that,
but
I
do
also
see
the
point
of
view
from
like.
There
are
a
lot
of
meetings
already
specifically
to
do
with,
like
the
specification.
D
All
right,
maybe
we'll
do
the.
D
Okay,
yeah
correct:
I
think
it's
okay
and
we'll
just
have
other
topics
as
well,
so
yeah
I'll
leave
it
to
james
and
folks
to
provide
the
topics
that
they
want
to
have
covered
and
we
can
discuss
those
as
well.
B
Okay,
so
the
next
item
on
the
agenda
last
time
on
this
meeting
we
talked
about
the
instrumentation
layers
and
suppression.
B
So
just
to
remind
that,
let's
say
we
have
a
database
call
which
is
internally
done
through.
Maybe
a
number
of
http
calls
and
then
basically
the
picture
we
want
users
to
have
is
that
they
have
a
database
and
maybe
nested
http
calls.
Maybe
some
users
don't
want
http
calls
at
all.
Maybe
they
want
on
the
database
call,
but
the
problem
we
have
beyond
those
layers
is
that
we
have
some
duplicated
instrumentation.
B
So
we
let's
say
we
have
multiple
http
client
using
each
other,
and
we
have
layers
of
http
clients
which
are
duplicates
and
they
don't
bring
a
huge
value.
So
I
had
some
discussion
tap
to
discuss
it
and
the
feedback
was
that:
how
can
we
do
it
through
open
telemetry
api
and
make
it
easier?
B
Ask
for
your
feedback,
so
what
I've
created
is
an
application
that
okay,
so
let
me
start
from
the
beginning,
so
this
this
application
creates
a
messaging
span
and
what's
different
from
how
we
usually
do
it,
is
it
visible
enough?
Is
it
good
should
I
increase
the
phone.
B
Okay
yeah,
so
basically,
this
is
how
we
would
normally
accept
this.
How
we
would
normally
create
a
span.
We
would
all
set
attributes
and
other
things,
but
this
is
the
bare
minimum
and
what
I'm
creating
is
a
new
method
on
the
builder.
It
depends
on
the
language
in
java,
it's
builder,
the
naming.
B
B
So
what
internally
happens
is
there
is
a
trick
there
we'll
we'll
talk
about
this,
but
what
internally
happens
that
with
notice
in
sdk
that
we
already
have
a
messaging
expand
started
and
we
keep
it
in
the
context.
So
when
we
start
a
new
span,
another
messaging
span
and
scope
of
that
one,
the
sdk
will
detect.
There
is
already
messaging
span
the
client
messaging
spend.
Let
me
suppress
this
one
and
by
suppression.
It
means
it
returns,
basically,
sampled
out
span,
so
this
guy
is
as
if
it
was
sampled
out.
B
Let's
talk
about
the
problems
here,
but
first
I
want
to
go
through
some
other
stuff.
So
first,
the
the
instrumentation,
as
you
can
see,
doesn't
deal
with
anything
with
any
configuration
here.
So
the
configuration
is
done
through
through
some
system,
property
environment
variable
anything.
So
basically
we
said
we
said
that
the
suppression
kind
here
and
with
this
suppression
kind,
this
duplicate
span
will
be
suppressed.
B
If
we
disable
suppression,
it
won't
be
suppressed
yeah
and
then,
if
we
create
an
http
span
under
it,
then
http
span
will
not
be
suppressed.
B
Okay,
so
the
the
that
we
have
the
suppression,
kind
and
type.
B
And
we
started
the
messaging
clients
pen,
let's
ignore
this,
for
a
second
is
it
like?
Is
it
recording?
No,
that
the
next
one,
the
duplicate
one?
No,
when
we
inject
context,
we
re-inject
exactly
the
same
context
and
if
we
want
to
start
http
span
yes
and
we
see
just
two
spans
are
exported,
one
is
http
and
another
one
is
messaging.
B
So
what
are
the
problems
with
this
approach?
There
are
two
problems,
the
first
one,
it's
not
very
efficient.
So
when
we
do
this,
we
we
kind
of,
let's
think
about
it.
We
create
all
the
attributes.
We
should
put
all
the
attributes,
we
should
calculate
them,
we
create
a
new
span.
B
The
other
thing
that
when
we
inject
context,
we
kind
of
re-inject
the
same
context
again,
which
is
not
a
functional
issue,
but
it's
a
performance,
it's
not
so
great
right.
So
basically
what
I'm
also
suggesting
it
may
be
separate,
but
it's
another
thing
on
top
that
I
would
like
to
see
is
a
hint
for
instrumentation
that
I
would
say
if
the
span
should
be
started
at
all.
So
this
is
like
a
pre-sampling
decision.
B
This
is
also
useful
in
this
case
right,
so
we
pass
the
kind
and-
and
we
get
this
this
as
a
hint,
so
even
without
this
optimization
things
would
work
so
people
who
want
to
have
an
easy
and
simple
api.
They
can
keep
using
it
for
people
who
are
interested
in
performance
like
instrumentations,
the
native
library
instrumentations
things
like
that,
they
will
be
happy
to
use
this
hint.
B
E
I
have
a
question:
I'm
not
super
familiar
with
this
otep,
but
there
is
what
kind
of
configuration
options
would
there
be
for
this?
Can
you
turn
off
those
like
suppressing
of
the
like
the
later
span.
E
B
It's
off
by
default,
so
I
I
I
think
it
should
be
on
by
default
honestly,
but
like
the
the
choice
of
the
default
sets,
I
think
it's
up
to
vendor
so,
but
if
it's
off
and
I'm
open
to
different
proposals
regarding
the
the
defaults
but
anyway,
so
if
it's
off
wait,
don't
you
yeah!
B
E
Yes
right,
it's
yeah,
okay,
okay!
I
don't.
I
can't
see
any
problem
with
that.
I
I
could
see
the
value
of
it
being
default,
but
I
could
also
see
it
confusing
someone
if
they
didn't
know
that
about
that
configuration
default,
configuration
being
like
hey
where's,
my
where's,
my
span
gone.
That's
the
that's!
My
input.
B
Yeah
it
smells
like
users,
then
they
just
stopped
in
into
the
instrumentation,
and
they
they
probably
don't
want
duplicate
so
like
by
saying
that
way
like
this
spam
conforms
to,
let's
say
messaging,
apply
like
there
is
no
client
messaging.
Sorry
for
this
example
anyway.
So
by
saying
that
I
conformed
to
this
specification
this
convention,
I'm
saying
that
whatever
whoever
else
underneath
me
tries
to
instrument,
probably
will
will
create
duplicates.
B
This
is
more
like
a
bug
than
it
doesn't
bring
much
user
value.
E
B
B
That's
at
least
my
impression
that
we
do
more
harm
than
good
is.
This
is
an
extra
cost
right,
so
for
http
you
have
a
tons
of
http
requests,
so
users
would
pay
like
twice
as
much
just
because
we
introduced
this
duplication
right,
so
it's
very
harmful,
and
probably
if
our
specification
are
strict
and
good
enough,
then
we
shouldn't
have
this
problem.
E
Yeah,
that
sounds
that
sounds
sensible
to
me.
I'd
I'd,
be,
I
think
that
would
be
useful
as
a
default.
F
Cool
in
in
the
ruby
implementation
we've
taken
sort
of
the-
I
don't
say,
the
opposite
approach,
but
kind
of
you're
dropping
like
a
child,
not
dropping
but
choosing
not
to
create
child
spans.
If
there's
like
a
parent
that
exists,
that
represents
like
the
clients
fan
for
for
the
ruby
implementation,
what
we've
been
doing
is
sort
of
the
opposite
direction.
So
say
you
have
this
higher
level.
F
Client
library
that
you
know
is
going
to
make
a
network
call.
Instead
of
generating
a
span
there.
It'll
set
some
attributes
that
get
propagated
downwards.
So
when
you
have
your
as
close
as
you
get
to
the
actual
network,
call
like
say,
like
ruby's
standard
net,
http
library
it'll
actually
enrich
those
fans
with
the
information
at
the
top.
So
we
get
rid
of
that
duplication
problem
and
we're
able
to
kind
of
accumulate
information
on
the
way
down,
and
so
it
also
allows
kind
of
application
owners
to
add
specific
things
as
well.
F
B
F
Information
down
and
because
I
think
it's
kind
of
it's
related
to
the
otep
at
the
server
stand.
We
do
the
same
thing
so
as
close
as
we
get
to
what's
accepting
that
request,
so
in
ruby
line,
it's
typically
what's
called
the
rack,
we
generate
the
rackspan
and
then
you
can
actually
enrich
the
rackspan
with
your
middleware
if
needed.
So
it's
on
the
in
on
the
way
in
we
generate
as
close
to
the
reception
of
like
the
request,
and
then
we
accumulate
information
and
add
on
to
it.
F
B
Yeah,
that
would
be
great
like
if
you
can
comment
present
how
actually
you're
doing
this,
because
there
is
no
open,
telemetry
mechanism
that
allows
you
to
enrich
spans.
That
will
be
created
right.
So
this
is
some
custom
solution
and
I'm
happy
to
hear
about
it.
F
But
I
think
what
we
need
to
do
is
kind
of
capture
that
and
share
it.
So
we
can
compare
notes
and
see
what
makes
sense,
because
I
think
there's
just
going
to
be
some
differences
between
languages
and
some
certain
conventions
make
more
sense
for
certain
languages
right.
But
we
need
to
find
something.
That's
at
least
consistent
for
the
people
who
are
using
it
across
languages.
B
Yeah
yeah.
I
think
that
the
problem
here
is
that
in
general
case
we
don't
know
if
there
is
a
network
instrumentation
right.
So
we
don't
now
we
might
have
a
plugable
http
client
and
some
of
them
are
instrumented.
Some
of
them
are
not,
and
we
have
users
who
do
make
symmetrical
instrumentations,
others
don't
so
like
with
some
instrumentation
layer.
We
cannot
just
say:
okay,
there
will
be
one
because
it
could
be
none.
F
Right
definitely
and
that's
something-
that's
been
kind
of
surfaced
through
documentation.
We
also
have
kind
of
this
instrumentation,
all
library,
that
if
someone
doesn't
want
to
think
about
it,
they
just
included
their
project
and
they
get
all
of
the
auto
instrumentation
so
that
it
just
works
out
of
the
box
for
for
your
typical
application
owner,
and
they
don't
have
to
think
about
all
of
them,
because
we
made
these
conventions
like
these
choices
right.
C
C
Yeah,
at
least
in
node,
I
know
that
sometimes,
for
example,
we
have
a
database
span
and
underneath
it
we
have
like
the
transport
span
like
a
http
of
or
in
aws
sdk.
We
have
the
like
the
aws
sdk
span
and
it's
it
has
http
span
downstream
and
usually
it's
not
very
interesting,
this
http
spam.
So
in
many
cases
we
just
want
to
suppress
it
because
it's
it's
not
giving
any
value
so
yeah.
B
C
B
It
will
so
remember,
we
had
a
configuration,
it
was
kind
and
tight,
so
we
can
have
kind
only
and
what's
going
to
happen,
if
I
spelled
it
correctly,
probably
not.
I
didn't
spell
it
right.
So.
B
C
C
C
And
also
regarding
your
performance
concerns,
like
I
think,
sampling
is
behaving
in
a
similar
way.
Well,
when,
at
least
in
a
node
where
you
were
where
you
have
a
sampling
decision
and
you
would
decide
not
to
sample,
you
still
collect
all
the
attributes
and
you
and
doing
all
the
work
you
just
drop
the
spend
later
on
before
exporting
it.
F
B
I
am
concerned
in
both
cases,
and
there
are.
There
is
a
discussion
on
the
specification
that
sampling
decision
happens
way
too
late
to
get
any
performance
benefits
from
it.
So
was
this
new
api
that
I'm
suggesting
you
can,
but
you
don't
have
to
use
it,
so
you
call
it
before,
and
you
see
you
don't
you
don't
even
allocate
anything
before
you
create
it.
B
So
like
nope
tracer
would
just
say
no,
but
like
the
the
let's
say,
the
operational
sdk
would
check.
Okay,
there
is
this
client
plus
type
on
the
context,
so
I'm
not
going
to
create
the
span
and
also
we'll
check
the
configuration
right
so
depending
on
the
configuration
it
will
check
if
the
the
span
is
already
present
and
okay,
let
me
suppress
it.
So,
basically,
the
instrumentation
every
instrumentation
that
cares
about
performance
would
add
something
like
this
and
if
it's
not
there,
then
just
back
off
any
instrumentation
at
all.
C
I
didn't
fully
understand
how
it
would
work
because
like
if,
if
we
need
to
inject
the
context,
so
we
will
probably
do
it
like
a
downstream
and
maybe
we'll
we're
dropping
this
spam
due
to
this
mechanism.
B
B
C
I
have
another
questions
in
a
messaging
when
we
have
a
cons
when
we're
consuming
a
message.
We
have
like
this
structure
of
two
spans
one
for
receive
and
one
for
processing,
and
they
both
will
be
labeled
as
a
messaging
right.
So
this
mechanism
can
it
has
a
potential
to
drop
one
of
them.
Probably
the
processing
span.
C
C
Otherwise
it's
a
problem
for
the
instrumentation,
so
something
that
we
should
check
that
there's
no
way
for
it
to
happen.
I
think
yeah.
B
I
agree
I
I
will
check
if
this
is
the
case,
if
they
are
both
the
same
kind
and
the
same
instrument,
and
then
we
probably
should
separate
the
the
instrumentation
type
and
the
more
the
messaging
thing
into
the
more
conventions.
B
C
A
A
For
that,
before
you
get
controversial
on
the
last
yes
here,
what
do
you
think
about
considering
suppressing
by
inbound
and
outbound
instead
of
by
kind,
meaning
like
client
span
and
producer
span
say
lumped
together,
I'm
thinking
of
like
say
a
messaging
client
that
produces
a
message
but
then
is
delivered
over
http.
So
there's
a
http
client
span
underneath
it.
B
So
what
what
I
think
that
we
can
do
this?
I
have
no
objections
from
separating
by
inbound
and
outbound,
but
what
I'm
also
going
to
discuss
during
the
messaging
spec
that
the
producer
we
shouldn't
mix
the
producer
and
the
client
spend.
So
if
it's
a
transport
call,
it
should
be
client.
If
it's
a
call
that
creates
a
message.
It's
a
producer!
That's
what
I'm
going
to
argue
for
on
the.
B
Okay,
so
now
forget
everything
I
told
about
the
layers:
this
is
a
puzzle,
so
think
about
sampling.
So
let's
say
the
server
span.
We
have
http
servers
pen,
it's
sampled
in
and
let's
say
we
have
an
http
controllers
pen
and
let's
say
we
have
a
sampler
that
samples
it
out.
We
can
certainly
do
it
right,
then.
Maybe
the
controller
instrumentation
sets
attribute
that
this
span.
We
create
the
sampled
out
span.
It
does
not
record
any
attributes.
B
B
So
is
it
that
the
sampled
in
server
span
or
it's
a
sampled
out
controller's
pen
so
how
it
works?
Now
it's
the
the
controller
stand
at
least
in
java,
so
when
user
set
attribute
in
this
case
thinking
they
set
it
on
something
real
goes
nowhere,
because
currently
it's
no-
and
I
argue
this
is
not
right.
This
is
not
what
should
happen.
A
Yeah
so
my
yeah,
so
my
the
we've
modeled
sampling
so
far,
the
way
at
least
the
way
it
works
and-
and
I
agree
like
it's-
I'm
not
sure
it's
correct,
because
I
would
love.
I
would
love
to
be
able
to
sample
out
something
in
the
middle
like
that,
like
a
controller
span
only,
but
since
the
samplers
like
do
the
parent
based
they're,
typically
parent-based,
and
so
once
you
sample
out
you're,
basically
sampling
out
the
whole
downstream
from
there,
which
is
what
you
want
sometimes
and
isn't
what
you
want.
B
A
A
F
So
this
is
an
interesting
example,
because
maybe
a
little
maliciously
we've
made
use
of
this
behavior
to
surface
this,
isn't
within
our
api
or
sdk.
But
it's
kind
of
like
a
supplementary
package
that
users
can
use,
but
we
provide
an
untraced
method,
so
they
can
actually
set
the
context
to
have
like
the
current
span,
be
non-recording
so
that
every
request
under
it
is
no
longer
recorded.
F
B
Right,
but
in
this
case
we
don't-
let's
say
we
don't
want
this
one
right
right,
right
like
it
doesn't
exist,
but
if
we
try
to
do
it
with
custom
sampler,
it
will
result
in
users
who
try
to
interact
with
this
current
span,
which
they
think
is
the
http
server
to
be
broken
right.
So
in
this
case
we
want
to
keep.
Let's
say
if
http
client
call
happens
here,
we
want
to
have
it
still.
B
I
know
so
that
the
controller's
pen-
it's
a
it's,
a
span
that
it's
a
fake
pen
right.
So
it's
a
sampled
outstanding,
it's
it.
It
has
the
same
context
as
parent,
because
it's
sampled
out
so
when
we
create
a
http
clients
pen,
it's
the
technically
sibling
of
this
controller's
pen,
the.
If,
if
you
like,
there
is
no
controller
span,
but
if
it
was,
they
would
be
siblings.
B
A
Yeah,
I
feel
like
sampling
would
need
some
like
to
be
able
to
samplers
would
need
maybe
another
result
code.
I
think
they
currently
have
like
drop,
and
I
forget
what
I
think:
there's
three
states,
but
something
that
says
to
suppress,
maybe
but
continue
the
trace.
B
Yeah
but
like
it's
at
the
sampler
type
right,
so
that
if
it's
based
on
the
parent
id
sorry
that
on
the
trace
id
the
probability
sampler
or
if
it's
a
sampler
that
is
based
on
parent
decision,
they
would
have
this
logic.
But
even
today
you
can
have
a
sampler.
B
B
A
Yeah,
I'm
thinking
so
with
the
controller
span
say
you
had
a
sampler
and
you
wanted
to
suppress
the
controller
span.
If
you
return
drop
today,
that
will
do
the
non-recording
span
and
put
that
in
the
context.
A
B
A
A
B
B
Yeah,
so
it
it
works,
it
works
with
the
was
the
case
where
you
want
to
enrich
local
route
right.
So
assuming
you
want
to
enrich
anything
except
focal
route,
it
will
be
a
problem.
I
I
agree
that,
like
the
whole
idea
of
spam,
current
is
very
fragile,
like
we
cannot
expect
it
to
work
all
the
time.
A
Yeah,
I
I
think
it's
a
little
bit
ambiguous
which
to
me
what
the
right
behavior
is
there,
because
a
lot
say
some
instrumentation
creates.
We
have
instrumentation
that
calls
start
span
and
it'll
get
sampled
out,
but
then,
in
that
same
instrumentation
we
do
augment.
We
call
set
attribute
after
start,
because
we
don't
have
some
attribute
available
on
start
and
that
probably
should
get
called
on
the
non-recording
span.
B
A
Yeah,
that's
a
good
point
the
span
so
that,
if
you,
if
instrumentations,
want
to
enrich
the
span,
they
should
use
the
span
that
they
created
to
pass
that
around
versus
arbitrarily
grabbing
the
current
span
from
the
context
yeah.
That
makes
a
lot
of
sense
to
me
and
we
we
should
be
able
to
do
that.
A
Fine
in
the
instrumentation,
because
we
have
to
pass
around
the
context
anyway
through
some
means
or
another,
and
even
if
it
is
in
a
thread
local,
we
can
always
put
the
span
in
that
instrumentation
can
always
put
its
own
span
under
its
own
key
context.
Key
and
pull
it
back
out
later,
yeah
yeah.
That
makes
sense
to
me
yeah,
because
otherwise
you're
right
that
current
span.
What
even
is
current
span
at
that
point.
B
Yeah,
so
basically,
I
think
that
the
the
summary
here
is
that
for
sampling,
it's
a
hairy
problem,
it's
hard
to
solve,
and
maybe
we
shouldn't
solve
it
with
for
the
current
span,
because
the
whole
concept
is
not
great,
so
maybe
we
should
introduce
some
local
route
or
other
shortcuts
that
we
discussed
in
the
previous
meeting
and
for
suppression.
It
sounds
like
this
is
the
the
main
idea
that
we
want
to
disable
certain
spans
while
preserving
their
children.
B
So
this
will
be
a
next
step
for
me
to
do
it
for
the
suppression
and
I'll
I'll
make
some
notes
with
what
we
discussed
regarding
the
different
things
today
in
the
document.
A
Cool,
I
like
the
idea
of
the
the
sampler
like
if
there
was
a
way
to
suppress
via
a
sampler
like
once
you
have
that
same
once.
You
have
that
mechanism
worked
out.
It
seems
like
it
would
be
straightforward
to
extend
that
to
the
sampler.
Have
another
sampler
decision
that
is
called
like
suppress
as
opposed
to
drop.
B
Yeah,
this
is
kind
of
tricky
because,
even
though
we
don't
want
with
sampler
right,
even
if
we
don't
want
the
this
controller's
pen
to
be
current,
if
http
server
span
is
sampled
out,
because
it's
a
local
route
and
we
should
have
a
span,
it
should
be
current.
Even
if
it's
sampled
out
right.
B
Right
yeah,
so
if
there
is
a
span
on
the
span
on
the,
if
there
is
a
current
span,
we
don't
want
to
set
sampled
out
span,
but
if
there
is
no
span
we
want
to
set
current,
and
this
is,
it
sounds
like
too
complicated.
A
I
will
yes,
I
will
look
forward
to
thinking
about
this
with
a
fresh
brain.