►
From YouTube: 2020-06-09 .NET SIG
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
A
D
E
C
Absolutely
today,
my
first
pull
request
to
kubernetes
was
merged.
E
D
Yeah,
I
don't
think
we
need
to
wait.
We
can
start
really
message.
He
won't
be
joining,
so
we
can
start,
let's
go
over
the
agenda
first.
The
first
item
is
to
update
the
meeting
time
so
about
like
four
weeks
back,
we
kind
of
decided
to
make
it
like
always
11
am
sergey,
was
the
only
one
who
had
4
pm
preference,
but
he
said
it
was
fine
to
have
at
11
am
so
just
want
to
ask
like
one
more
time.
D
D
Okay,
so
should
I
do
like
a
doodle
thing
to
figure
out
like
more
thing
or
we
can
just
fix
like
what
we
are
following
is
going
to
work
at
least
we'll
get
alternate
week,
so
people
who
cannot
make
it
at
11am
can
make
it
4pm,
so
we'll
have
some
representation
from
one
of
the
maintainers
every
other
week.
D
Okay,
let's
go
to
the
next
one,
beta
timeline
and
formal
announcements.
I
don't
think
I
have
anyone
else
from
microsoft.
Who
can
talk
more
about
it?
I
was
hoping
ankit
or
someone
would
help
here,
but
since
they're-
not
here
I'll,
probably
have
to
skip
to
the
next
item.
D
But
there
are
several
people
who
are
asking:
when
are
we
going
to
have
a
beta
shipped?
D
My
I
think
my
straight
answer
would
be
as
soon
as
we
are
done
with
the
activity
changes,
and
then
we
are
at
a
stage
where
we
can
use
both
the
span
api
and
activity
api
interoperably.
Then
that
should
be
a
good
time
for
us
to
call
beta
and
around
the
same
time
we
can
like
make
the
decision
whether
activity
api
is
meeting
all
our
requirements,
and
then
we
can
formally
like
kill
the
span
api
and
just
leave
with
the
rapper
like
mike
mentioned
today
morning
that
he
is
already
working
on
a
wrapper.
D
So
when
is
that
going
to
happen
from
the
current
progress,
it
should
be
very
soon,
because
let
me
just
take
that
issue,
so
we
have
two
things
which
are
competing
with
each
other.
I
don't
think
anyone
is
actively
tracking
the
beta
dinner
striker
but,
like
I
said
if
this
is
done
like
as
soon
as
we
get
closer
to
this
being
done,
we
should
be
able
to
call
ourselves
beta
so
like
this
should
be
like
in
apr
right
now.
Everything
in
three
should
be
like
converted
in
covered
by
a
single
pr.
D
We
still
have
items
left
in
sampling,
some
of
the
procures
change
from
dotnet-
let's
go
over
it
later,
but
everything
else
is
like
relatively
small
thing
like
adding
zip
in
z
pages
should
be
very
straightforward.
D
These
should
be
very
straightforward
benchmarking
here.
So
that
can
probably
wait
so
like
I
don't
really
know
whether
alexa
gay
or
do
you
know
like
if
there
is
anyone
who
wants
to
try
it
even
in
who
wants
to
try
it
but
they're
not
trying
it,
because
we
are
not
officially
calling
it
beta
and
not
releasing
to
nougat.
Then
we
can
make
alternate
some
arrangements,
but
as
of
now,
I
see
like
as
soon
as
we
have
most
of
the
items
from
this
completed
and
we
have
both
activity
ap
and
span
apa.
D
C
One
of
the
things
we
can
discuss
here
when
we
go
to
beta
is
this
pull
request
into
kafka
and
radius
client
that
use
to
today's
expo
request
like
drafts
using
current
diagnostic
source
apis.
Do
do
you
want
to
try
out
a
new
approach
with
activity
source.
D
It's
questionable
because
I
don't
know
whether
those
libraries
are
willing
to
take
dependency
on
the
preview
package
of
diagnostic
source,
because
when
I
talk
to
grpc,
they
won't
be
able
to
take
it.
They
will
wait
for
diagnostic
source
to
be
like
released
ga
before
they
can
start
moving.
I
don't
know
whether
the
same
restriction
applies
for
freddy's
or
any
other
libraries.
F
I
mean
the
reddest
one
that
I
have
out
there
isn't
doing
either
it's
just
expanding
the
the
profiling
api
that
they
already
have,
and
then
it's
our
adapter
that's
building
the
span,
so
it
could
do
either
way
the
cough
go
on.
I
don't
know
we
haven't,
got
any
feeling
from
them
on,
if
they're
even
open
to
it
at
all.
F
D
So
sergey
like,
why
do
we
like?
Is
that,
like
a
good
thing
nice
to
nice
thing
to
have,
or
is
there
any
other
reason
why
we
want
to
know
about
that
or
block
on
that.
C
Yeah,
I'm
just
asking
whether
we
have
enough
validation
of
those
apis,
because.
D
C
Use
cases
with
current
set
of
collectors,
then
it's
probably
fine
yeah.
D
So
that's
that
probably,
is
the
only
value
because
everything
else
which
we
currently
have
it
uses
a
old
diagnostic
source
based
instrumentation
and
we
just
have
adapters
converting
it.
So
the
only
like
it's
not
strictly
true,
but
the
closest
thing
which
we
have
for
a
library
to
be
fully
using
the
activity
source
is
http
client
for
net
framework.
D
D
I
can
make
that
change
yeah,
but
question
is
like
do
we
have
to
wait
for
that
to
call
ourselves
beta
or
we
can
call
ourselves
beta
like
as
soon
as
we
are
done
with
more
items
from
here
and
then
like
decide
on
like
what
to
do
with
other
libraries
like
kafka
and
reduce.
D
A
Yeah,
just
just
because
they
are
related
to
this
and
you
you
just
had
that
pr,
I
think
you
are
already
merged
with
the
updated
activity
source
right.
Sorry,
your
voice
was
breaking.
Can
you
just
repeat,
did
you
update
you
already
merged
that
one
with
the
updated
activity
source
right?
So
I
think
I
can
remove
some
code
that
we
had
dealing
with
the.
A
The
trace
context,
even
if
it
was
not
sampled
sampled,
because
we
need
to
be
able
to
track
that
for
the
remaining
decisions
that
you
do
for
child,
even
if
the
activity
was
not
created.
You
know
I
will
open
separate
the
issue
for
that.
Okay,.
D
Yeah
one
or
two
follow-up
issues
from
this
pr,
like
one
of
them,
is
what
you
just
mentioned,
and
the
second
one
is
the
trace
id
of
the
yet
to
be
created,
activity
being
fed
into
sampler,
but
it's
not
going
to
be
the
actual
one.
So
I
remember
like
these
two
were
the
open
issues
and
yeah.
We
have
like
one
more
topic
to
discuss
towards
once.
We
like
michael,
has
some
proposal.
D
Nova
has
some
comments
on
that
so
yeah
and
one
of
the
outcome,
or
one
of
the
things
which
we
noted
in
that
proposal,
is
about
the
trace
id
being
not
used.
The
one
the
trace
id
being
fed
into
assembler
is
not
the
one
which
is
actually
used
when
the
activity
ends
up
creating
yeah.
So
let's
get
to
it
right
after
this.
So
did
you
have
any
other
concerns
with
this
overall
plan.
G
I
had
a
quick
question
just
about
the
beta
timeline
stuff.
Does
it
include
or
where
does
support
for
metrics
fit
in
the
timeline.
D
That's
a
good
question.
I
let
me
come
back
to
it
like
before
the
next
meeting,
because
I
don't
know
whether
we
should
be
updating
the
current
metrics
sdk
with
the
newest
spec.
D
D
Yes,
because
when
we
tracked
this
original
issue,
where
we
were
tracking
beta
readiness,
we
already
had
covered
like
matrix
again,
it's
a
bit
gray
area
because,
like
what
it's
really
says,
is
sdk
implementation
of
every
spec
feature
for
matrix,
and
there
is
no
sdk
specification,
it's
it's
blank,
so
we
can
technically
say
we
are
already
beta
because
it's
it's
zero,
like
we
already
implemented
zero,
so
you
can
already
say
that,
but
let's
at
least
try
to
do
like
what
other
languages
are
doing
and
we
have
like
almost
all
the
api
ready.
D
The
sdk
implementation
is
mostly
ready.
I
think
we
have
issues
open
just
to
track
like
what
exactly
is
missing.
So
I
would
say
to
answer
your
question
when
we
say
we
are
ready
with
beta.
Yes,
it
would
include
the
matrix
in
its
point
to
your
point
for
state
right,
okay,
yeah.
What
I
really
meant
to
say
is:
it
won't
include
the
latest
like
this
is
the
most
latest
one
it
contains
like
seven
set
of
like
five
or
six
counters.
D
D
Okay,
yes
yeah.
We
have
one
topic
here
to
discuss
and
then
I
would
like
to
use
the
remaining
time
to
discuss
the
sampling
question
and
things
like
that.
So
I
will
ask
again
this
question.
So
do
you
know
like
what's
the
story
with
baggage
like?
Is
it
supposed
to
be
just
part
of
like
part
of
expand
out
attributes
or
activity
dot
tags
and
what,
if
it
is,
then
why
are
we
not
doing
it?
Is
it
just
an
oversight
or
was
there
a
reason.
C
You
need
to
define
your
own
telemetry,
processor
or
spam
processor
that
will
take
values
from
baggage
and
associate
with
suspense,
if
you
need
to
so,
you
need
to
explicitly
tell
it
so
or
some
other
mechanism,
mostly
because
activity
baggage
can
carry
some
pi
information,
and
nobody
wants
to
mistake
like
to
to
report
to
the
back
end
some
information
that,
like
user
user
id
or
something
like
that,
that
may
harm
the
back
end.
D
Okay,
so
it
can
be
either
like
users
can
write
their
own
spam,
processor
or
activity
processor,
or
we
can
make
it
a
flag
like
populate
baggage
and
do
tags,
and
then
we
can
do
it
also,
but
it
should
be
opt-in.
That
should
be
the
key
takeaway.
C
D
Yep
got
it
and
like
I
think
this
was
already
clear
like
there
was
some
confusion
about
tri-state
versus
correlation
context,
and
I
mean
like
whoever
has
the
most
knowledge.
Can
you
just
share,
like
my
understanding
is
trace,
state
is
part
of
the
w3c
spec
and
trace
state
is
where
you
can
put
any
vendor.
Specific
information
and
correlation
context
is
completely
different.
It's
not
yet
a
w3c
spec,
so
it
can
be
used
by
users
to
set
any
additional
key
value
pairs
which
they
they
can
potentially
use
to
augment
the
telemetry.
C
Yes,
so
thank
you
so
one
of
the
useful
trace
states
that
is
currently
in
consideration.
This
is
conval
from
microsoft
senate.
It's
a
propo
like
propagation
of
a
sampling,
priority
flag
and
assembling
priority
flag
theoretically
will
be
needed
not
only
on
sdk
itself,
but
also
on
collector
or
back
end.
So
collector
of
backend
can
do
additional
sampling
or
like
react
on
this
message.
So
trace
state
should
be
expected
by
default
when
possible.
D
Okay,
make
sense,
yeah,
okay,
so
that
clarification
we
need.
The
only
work
item
we
need
is
as
of
now.
We
can
leave
it
as
it
is
because
we
are
not
acting
on
baggage.
Users
can
write
their
own
processor
to
opt-in
and
we
can
optionally
make
it
part
of
the
sdk
itself.
So
user
doesn't
have
to
write
the
logic
they
just
turn
on
a
flag
and
read
people
play
package
into
text.
Okay,
make
sense,
okay,
so
yeah.
This
is
what
riley
put
about
changing
the
metadata.
C
I
don't
know,
but
you
all
should
have
permissions.
Oh
okay,.
D
I
think
you
sent
an
email,
so
I
should
have
a
way
to
get
admin
rights
to
this
package
and
we
can
go
and
see
how
to
rate
this
one.
D
D
D
Yeah,
okay,
so
let
me
take
that
use
my
permission
and
see
if
I
can
change
it
and
then
there
are
like
others,
smaller
things
which
I
don't
think
we
need
to
discuss
in
the
whole
group.
Okay,
so
we
can
change
this
url
to
our
url
and
probably
change
the
tags
yeah
we
I
did
see
like
these
tags
may
not
like
management
tracing.
So
do
you
know
like
where
is
this
source
or
it's
in
the
new
spec?
D
A
B
Oh,
I
I
so
I
just
I
was
I
was
peaking
down.
I
just
wanted
to
mention.
We've
got
william
and
barry
joining
from
the
vs
diagnostics
team
that
those
guys
they
work
on
clr
instrumentation
engine
which
we
were
talking
about
last
week.
B
So
I
don't
know
if
you
guys
had
follow-up
questions
from
last
week's
discussion,
but
I
I
asked
them
to
come
and
at
least
say
hello
and
introduce
themselves
and
and
of
course,
if
you
have
questions
you,
could
you
can
ask
them.
I
Hi,
I'm
barry.
Can
you?
Can
everyone
see
me?
Yes?
Yes,
okay,
okay,
I'm
I'm
new
to
zoom,
at
least
from
a
work
context.
Anyway,
I
am
the
engineering
manager
on
the
visual
studio,
diagnostic
team
and,
like
noah
said,
like
you
know,
we
have
a
component
called
ie
that
I
think
folks
here
are
interested
for
some
collaboration
and
thanks
to
noah,
to
connect
us.
J
Yeah
and
hi,
I'm
william,
I
don't
have
a
camera
because
I'm
working
on
my
desktop
my
laptop's
having
some
issues,
but
I'm
a
dev
on
the
underberry,
and
I
our
our
team,
does
a
lot
of
work
with
the
information
engine
project
and
I
am
kind
of
the
main
driver
of
the
github
repo
for
it.
D
Nice
to
meet
you
too
yeah.
There
were
a
lot
like,
probably
I
think
you
should
know
greg
from
microsoft
he's
moving
to
datadog
next
week.
He
will
he's
not
here
today,
but
he
was
also
very
much
interested
in
the
instrumentation
engine
and
like
profiler,
all
those
things,
and
we
also
have
like
a
separate
channel
in
jitter.
D
Just
for
this,
like
the
general
idea,
is
we
use
the
second
half
of
this
meeting
to
discuss
our
instrumentation
and
if
the,
if
it
becomes
like
really
big
with
enough
participants,
then
we
can
probably
spin
it
off,
but
as
of
now,
we'll
just
use
this
meeting
itself
to
discuss
anything
related
to
our
instrumentation
by
the
way
is.
Was
there
any
topic
to
be
discussed
on
instrumentation
engine
or
anything?
D
Otherwise,
I
would
like
to
spend
some
time
on
other
feedback
which
michael
has
about
the
activity
source
and
stumbling,
so
it
probably
is
going
to
take
longer.
So
I'd
like
to
make
sure
we
address
any
other
concerns
before
we
go
into
that.
B
A
Not
yet
from
my
part,
I
was
thinking
trying
to
do
an
adapter
that
work
both
with
the.
A
Instrumentation
engine
and
the
profiler
apis
so
kind
of
trying
to
extract
the
common
code
so
that
I
kind
of
give
the
path
for
what
greg
was
mentioning
last
week:
kind
of
for
the
data
data
dog
stuff
to
to
go
that.
So
I
was
just
thinking
about
doing
that.
I
really
didn't
look
at
the
details,
but
I
thought
that
perhaps
a
prototype
on
that
kind
of
line
would
be
helpful
for
us
to
flush
out
stuff.
B
Okay,
I
do
just
j,
just
james,
I'm
trying
to
think
of
james
ever
shows
up
to
this
meeting
like
if
he
was
here.
I
don't
recall
if
he
was
in
this
meeting
last
week
or
not
he's
another
microsoft
person
interested
in
this
bytecode
instrumentation
space,
and
I
think
he
was
also
doing
some
prototyping
in
this
area.
So
I
my
only
thought
there
was
to
make
sure
that
I
connected
the
two
of
you
together,
so
that
you
know
make
sure
you're
not
like
needlessly
duplicating
any
any
work.
B
B
I
I
mean
definitely
doable
you'll,
just
see
like
the
difference,
basically
between
what
it's
like
to
write:
the
instrumentation
straight
to
the
underlying
icore
profiler
api,
and
what
it's
like
to
do,
the
instrumentation
with
sort
of
the
extra
abstractions
that
clr
instrumentation
engine
gives
you
I
will
or
barry.
I
don't
know
if
you
guys
have
any
more
thoughts
around
that.
J
That
about
covers
it,
noah
yeah,
it's
supposed
to
be
a
little
bit
easier
to
use
and
the
clr
instrumentation
engine
apis
are
sort
of
designed
to
allow
multiple
instrumentations
to
occur,
and
that's
why
there
are
some
decisions
that
was
made
to
to
make
that
happen.
So
there
are.
There
are
some
caveats
in
terms
of
calling,
for
example,
you
get
il
function,
body
allocator.
J
D
Generally
ask
folks
to
write
in
agenda,
so
we
know
if
there
is
any
specific
questions
for
more
folks
to
join,
but
usually
no
one
writes
it
anything
into
agenda.
So
I
would
really
ask
if
there
are
questions
specifically
to
any
team
within
microsoft
and
you
want
their
representation.
D
Then
please,
let
us
know
in
the
head,
so
we
can
bring
the
right
people
other
ways
like
most
people
like,
for
example,
like
william
may,
not
really
care
about
other
things,
open
telemetry,
so
just
to
make
best
use
of
everyone's
thing,
and
other,
like
I
know
like
my
michael
from
microsoft,
is
very
much
into
this,
but
he's
on
vacation
until
then
probably
another
week
or
so
so
he
should
be
back
by
mid-june.
Then
we
probably
have
more
updates
from
microsoft
side
as
well.
D
All
right,
let
me
I
assume
there
are
no
other
open
questions.
So
if
there
are,
please
do
raise
some
now.
Otherwise,
let's
move
on
to
some
what
more
involved
technical
topics
so
michael,
do
you
want
to
like
like
work
over
you
because
sergey
and
maybe
other
folks
are
not
really
familiar
with
your
proposals
and
it
has
got
like
really
long,
so
it
may
not
be
feasible
for
anyone
to
just
go
and
read
it
right
now.
D
So
could
you
just
summarize,
like
the
key
things
of
your
proposal
and
what
that
would
solve?
I
anything
he
can
help
noise
already
here.
So
we
can
hear
from
what
he's
thinking
from
a
dot-net
api
on
our
perspectives.
D
Do
you
want
to
like
share
your
screen?
If
you
want
to
like
show
something,
or
you
can
just
talk,
while
I'm
scrolling
through
here.
B
D
D
Summarize
the
like
root
of
the
issue,
which
you're
trying
to
fix
like
you're,
saying
that
the
api
is
not
user
friendly
so
but
just
to
give
everyone
the
full
context.
It
would
be
helpful
if
you
can
just
describe
the
issue
and
then
we
can
look
at
the
proposal
and
then
how
more
folks
coming
down
here.
F
F
F
F
So,
in
order
to
implement
a
couple
of
the
the
spec
samplers
like
probability
or
the
defer
to
parents,
you
need
to
kind
of
unwind
this
logic
here
and
it's
not
easy
to
do.
I
had
to
read
basically
the
the
source
on
github
really
closely
and
go
back
and
forth
with
noah
and
some
of
the
experts
to
even
kind
of
land
on
here,
which
I
think
is
close,
there's
still
some
like
gray
area
around.
Do
we
use
propagation
data
or
none
for
the
not
recorded
open,
telemetry
state?
F
I
just
feel
like
this
part,
is
too
complicated
for,
like
the
average
person
we're
not
average,
we
have
a
lot
of
knowledge
here
about
what
needs
to
happen.
We
could
probably
build
this
an
open
telemetry,
but
I
feel
like
the
api,
should
do
a
better
job
of
like
passing
back
in
okay,
here's,
the
parent
state,
here's
the
current
state,
which
is
kind
of
this
static
local
right
here.
If
that
makes
sense,.
D
F
K
F
I
feel
like
the
sampler
should
get
two
things
I
should
get
like
what's
going
on
currently
and
here's
what
I
know
about
the
parent
there's
also
another
issue
on
here
where
I
did
a
little
bit
of
a
bigger
kind
of
scratch
api,
where
I
actually
introduced
the
concept
of
an
activity
sampler
into
the
dot
net
api,
so
that
it's
not
so
much
like
a
callback
thing
in
the
current
one.
There's
a
parent
and
a
there's,
a
parent
idea
id
and
the
context
one.
F
I
don't
really
understand
the
differences,
so
I
tried
to
combine
those
two.
We
haven't
really
scratched
the
surface
surface
of
the
parent
id
case.
I
don't
really
know
how
what
we're
supposed
to
do
with
that,
but
so
it's
just
kind
of
me,
spitballing
and
trying
to
kind
of
present
like
why.
I
think
it's
difficult.
B
Yeah,
so
I
mean
I
can
chime
in
so
so
yeah.
I
think
the
that
well
in
terms
of
discussion,
I
think
the
trace
id
is
the
easy
part.
I
totally
agree
with
you.
The
spec
says
it's
supposed
to
be
there
we're
not
providing
it.
B
We
got
to
fix
something
in
the
in
the
runtime
api,
so
that
one
at
least
is,
I
think,
easy
to
square
away
discussion
wise,
we'll
have
to
figure
out
like
the
details
of
exactly
how
we
fix
it,
but
no
disagreement
definitely
needs
to
be
fixed,
then
the
the
other
one,
I
think
is
where,
like
the
discussion
is
more
interesting.
B
B
Right
so
my
well,
I
guess
couple
things
so
one
thing
is,
I
guess,
the
the
sdk
doesn't
specify
how
the
samplers
should
be
constructed.
It
just
says
that
they
should
exist,
and
so
my
assumption,
which
is
not,
I
believe
not
anywhere
in
the
spec
just
my
assumption-
is
that
the
way
you'd
build
the
samplers
is
you'd,
build
them
as
a
component
on
top
of
the
sampling
api
that
the
sdk
also
says
much
must
exist
that
that's
not
the
route
you
chose,
and
I
think
that
I
mean
that's
a
legitimate
option.
B
As
far
as
I
can
tell,
the
spec
doesn't
specify
one
way
or
the
other.
You
said,
I'm
not
going
to
build
it
on
top
of
the
spec
sampling
api,
I'm
going
to
build
it
right
on
top
of
net's
api
and
so
okay,
so
so
that
was
one
thing
which
was
unexpected,
but
but
fine,
I
think
it's.
F
B
Right
so
so,
let's
see
cup,
so
you
raised
the
thing
with
the
parent
id
my
impression
parent
id
is
intended
for
folks
who
are
using
the
old,
hierarchical
idea,
which
is
not
w3c
compliant
like
it's
just
a
different.
B
The
only
reason
it's
there
is
because
we
didn't
want
to
sort
of
kill
back
compatibility
for
people
that
are
using
it.
However,
I
don't
think
that
open
telemetry
is
under
any
particular
obligation
to
be
compatible
with
an
old
microsoft,
specific
standard,
and
so
I
would
assume
the
easiest
thing
to
do
for
open
telemetry.
B
Is
you
just
tell
the
users?
We
don't
support
that,
like
don't
use
that
old
thing,
if
you
want
to
use
open,
telemetry
and
then-
and
then
probably
your
you
know,
your
your
callback,
for
that
is,
is
a
no
op.
You
you
just
ignore
it
completely,
and
if
users
use
it
anyway,
you
just
like
that
too
bad.
We,
we
don't
accept
that
so
that
that
would
be
my
suggestion
for
parent
id.
B
So
so
the
the
ot
spec
says
that
you
get
the
sampling
flag,
but
you
don't
get
the
recorded
flag
like
by
design
and-
and
so
it
seems
like.
A
lot
of
the
challenge
here
is
that
you
are
trying
to
reconstruct
that
recorded
flag,
even
though
the
ot
spec
says
that
you
shouldn't
get
it,
and
I
also
think
that
you
shouldn't
need
it,
and
so
I
I
think
that's
where
a
lot
of
this
challenge
is
coming
from.
D
So,
just
to
make
it
clear,
like
the
the
algorithm
which
open
elementary
the
api
for
sampler
from
open
telemetry,
has
a
bunch
of
parameters
right.
I
believe
the
activity
creation
options
is
a
one-on-one
match
with
that.
D
As
long
as
that
is
the
case,
then
we
we
wouldn't
be
missing
anything
at
all,
because
the
spec
says
give
these
are
the
parameters
possible
by
making
sampling
and
I
believe
this
activity
creation
option
is
an
exact
one-on-one
match
with
what
spec
says
like
michael?
Can
you
confirm
whether
this
understanding
is
correct,
because
this
is
the
basis
of
like
whatever
we
discuss
next.
F
D
Actual
required
arguments
for
something,
no
matter
what
the
algorithm
is.
These
are
the
parameters
it
has.
The
parent
span
context,
so
we
have
in
the
activity
creation
option.
We
have
the
parents
activity
context.
We
have
this
one
we
already
know
trace
id
of
the
span
to
be
created
is
missing
so
that
we
already
agree.
It
should
be
fixed
name
of
the
span
to
be
created,
and
there
is
also
a
caveat
that
it
can
be
changed
afterwards,
so
that
is
already
passed
in
creation
options
and
spanking
initial
set
of
attributes
and
links.
D
These
three
are
also
part
of
the
activity
creation
options.
So
basically
this
means
like
we
are
already
in
compliant
with
the
spec
and
that's
what
nova
is
trying
to
say
like
we
are
already
this
current
api
is
already
in
sync
with
what
the
spec
allows.
D
So
there
should
be
like
no
need
of
providing
anything
more
than
what
is
already
available
in
activity
creation
options
aboard
the
parent.
We
don't
know
whether
parent
was
is
recording
or
not,
and
that
is
fine
because
suspect
doesn't
warrant
that
being
passed.
B
Yeah
did
I
get
that
correct,
for
I
mean
for
my
from
my
perspective.
Yes,
I
yeah
okay.
D
Yeah,
michael,
like
did,
I
get
it
correct
from,
or
did
I
miss,
represent
some
of
your
thoughts
here?
No,
that
makes
sense.
D
Let's
see
like
if
this
assumption
is
correct,
then
let's
see
what
what
is
the
reason
behind
we
need
this
logic.
I
I
didn't
read
it
sorry,
so
I
I
have
to
like
read
on
the
go
and
tell
so
here:
are
we
trying
to
determine
the
parent
parent
dot
is
recording
in
span
world
or
parent
right
is
all
data
requested
in?
D
F
F
D
And
what
what?
Why
do
you
think
that
is
because,
if
the
previous
statement
is
correct,
then
we
shouldn't
need
this
to
make
that
sampling
decision
right.
B
I
mean
it
yeah
you're
using
it
it
I
mean
it
looked
like
the
the
sample
code.
B
C
So
simple,
yeah
you're
right
probability,
sampler
is
for
sampled
flag
and
the
recorded
flag
is
typically
used
when
you
want
to
record
something,
but
you
don't
care
whether
it
will
be
sampled
or
not.
For
backhand.
C
So
one
example
is
in
azure
application
site.
There
is
a
live
stream
matrix
and
you
can.
You
may
want
to
record
all
spans,
because
this
feature
allows
you
to
show
all
spams
on
the
backend,
but
you
don't
necessarily
sample
all
the
spends,
because
you
still
want
to
send
one
out
of
hundred
to
the
back
end.
A
C
A
B
So
so,
if
I
had
to
guess
this
is
probably
coming
down
to
some
ambiguity
in
the
spec
language
and
then
and
then
michael
made
his
best
interpretation
of
the
ambiguous
language
there,
sort
of
assuming
that
that
we
should
replicate
all
three
states
of
the
there's,
a
record
not
record,
and
a
record
and
sampled
and
and
michael
you
are
trying
to
mirror.
You
know
whatever
the
parent
has
for
that,
do
the
same
thing
for
the
child,
and
I
and
I
think
the
spec
actually
doesn't
doesn't
need
that
to
happen.
B
B
F
F
Doing
that
here,
if
we
just
take
out
that
last,
I
don't
know
conditional
there,
I'm
trying
to
reconstruct
the
all
data
right
if
we.
B
F
B
B
F
So
my
whole
kind
of
thing
was:
if
you
imagine
this-
execute
parent
or
else
logic
without
that
static
local
and
it's
just
being
passed
in
okay,
here's
what
the
parent
was.
Then
it's
really
just
those
three
blocks.
It's
it's
really
simple
and
you
know
there's
not
any
dark
magic
like
if
you,
if
you
consider,
then
the
static
local.
You
know
you're.
Looking
at
the
context
was
it
default
a
lot
of
these
little
intricacies.
You
really
have
to
know
what
the
implementation
is
doing
with
the
results
in
order
to
kind
of
do
it
in
reverse.
B
B
D
Five
peers
already
waiting
to
update
the
sampling
spec
in
the
spec
repo,
and
there
are
at
least
ten
issues
on
the
all
the
four
years
for
trying
to
modify
the
probability
sample
so
yeah.
I
expect
some
features
to
be
there,
but
like
just
on
related
topic,
one
of
our
options.
If,
if
indeed
calls
for
more
things,
then
tottenham
is
providing
like
what
would
be
our
like
deadline
to
make.
That
is
it
still
like?
D
B
It
happen,
so
I
think
we
don't
have
tarik
here
today.
Do
we
no
okay
yeah,
so
I
mean
I
think
I
don't
have
any
updates
beyond
what
tarik
shared
and
I
think
what
he
shared
last
time
was
basically
to
say
that
as
long
as
he
gets
the
feedback,
what
was
that
by,
like
the
middle
of
this
month,
18th
that
that
that
represents
sort
of
the
ideal,
the
ideal
time
time
frame
under
which
he
can
respond
and
and
turn
it
around?
B
A
C
So
this
is
something
which
we
have
to
write
anyway,
like
it's,
not
just
yeah.
The
question
is
sidja.
Have
you
started
working
on
this
document?
Comparing
the
apis.
H
C
D
So
yeah,
so
I
hope
that
dog
walked
down
like
as
soon
as
my
current
pr
is
merged,
because
I
considered
that
pr
as
one
important
piece
which
can
unearth
any
issues
with
the
activity
api.
So
that's
why
I
was
like
really
focusing
on
just
that
piece
and
nothing,
not
anything
else.
Hopefully
it's
done
and
I
can
work
on
that
talk
real
soon,
but
that
should
like
give
us
what
are
the
issues
which
are
potentially
going
to
be
changed
and
which
require
like
bigger
than
trivial
changes
in
dot
net
right?
I
A
A
little
bit
to
to
the
the
the
discussion
about
the
the
parent,
I
I
think
the
main
difference
that,
if
I
remember
correctly,
is
because
synthetic
telemetry
always
create
a
span
even
if
it's
not
going
to
be
sampled
or
recorded
yep,
you
are
in
a
child
spend,
but
then
you,
you
know
that
it's
not
a
root
span
and
you
are
using
the
same
trace
id
so
that
can
potentially
affect
the
result
of
the
the
the
sampler.
A
So
if
I
recall
correctly,
when
I
did
that
change,
my
impression
was
that
we
needed
to
put
because
right
now
we
have
the
the
current
activity,
if
one
was
recording
at
least
is
created.
A
But
if
it's
not
recording,
we
need
also
to
keep
the
let's
say
the
context
of
that
trace
id
so
for
child
spends
even
expands,
even
if
they
are
not
created.
We
keep
the
trace
id
in
the
context
and
keep
using
that
to
any
child
spam.
Even
if
it's
not
recorded.
B
So
so
what
I
would
expect
to
happen
right
now,
and
I
think
this
is
gonna
work,
but
you,
let
me
know
if
there's
a
problem
is
that
as
soon
as
soon
as
you
as
soon
as
you
return
any
result
other
than
none
from
the
listener
in
in
the
activity
data
request,
then
the
activity
will
be
created,
it
will
be
populated
into
activity.current
and
whatever,
whatever
trace
id
got
used
for
that
activity
will
also
be
used
for
any
child,
and
so,
if
you
let's
say
you
create,
so
you
create
a
new
root
activity
because
you
return
back,
I
don't
know
propagation
data
or
something
like
that.
B
So
activity
gets
created,
activity
current
gets
populated.
Now
you
have
your
root
activity
and
then
a
whole
bunch.
More
activities
come
and
you
just
return.
No,
no,
no,
no,
no
none
to
ignore
all
of
them,
and
then
eventually
you
come
across
some
other
activity
and
you're
like
okay,
this
one's
important.
I
want
to
make
sure
that
one
gets
created
that
one
will
get
parented
to
that
very
first
root
span
and
it
will
have
the
same
trace
id
that
that
root
span
did
so.
As
long
as
the
root
span
exists,
the
trace
id
will
be
preserved.
B
Sure
so,
if
that,
if
that
happens,
we
throw
it
away
and
then
some
next
span
comes
and
and
we
create,
and
when
that
span
comes,
we
create
a
new
trace
id
for
it
like
a
new
random
number.
We
just
generate
one
out
of
thin
air
and
as
far
as
I
can
tell
that
should
be
legal
like
like
as
far
you
know,
you
completely
ignored
that
previous
span
and
that
previous
span
was
the
only
time
that
that
previous
trace
id
had
ever
been
used.
B
A
Yeah,
but
but
the
difference
between
open
telemetry
in
this
case
is
that
the
trace
id
of
the
root
span
is
never
lost,
so
the
child
spans
keep
having
the
same
trace
id.
So
so
suppose
you
did
the
sampler
based
on
some
bits
of
the
trace
id
you
you,
even
if
you
decide
to
not
sample
or
record
the
the
the
top
one,
the
root
span
that
race
is
preserved
for
all
the
the
children
see
see
joe.
Can
you
scroll
up
to
the
probability.
F
B
F
F
So
this
is
another
thing.
I've
been
learning
as
I've
been
going
through
this
with
noah.
Is
that
our
implementation
today
that
cjo
did
it
returns
all
data
and
recorded
or
none?
If
you
do
none,
you
basically
are
just
chopping
off
the
head.
You've
lost
it,
nobody
can
decide
later
on.
Then,
oh,
I
actually
want
to
sample
this
thing.
Really
all
our
samplers,
my
understanding
of
it
is
they
should,
at
the
minimum,
return
propagation
data.
F
B
Yeah,
it's
an
optimization,
you
don't
have
to
do
it.
You
could
just
you
could
return
propagation
data
every
time
and
you'll
create
a
new
span
or
new
activity
every
time,
but
you
could
optimize
it
further.
By
saying,
I
only
want
to
create
the
very
first
one,
that's
going
to
capture
the
trace
id
and
then,
after
that,
I'm
just
going
to
feel
free
to
throw
away
everything
that
I'm
not
planning
on
recording
and
then
at
some
point.
If
I
actually
want
to
record
something
I'll
I'll
record,
it.
D
F
B
D
B
Make
sense
yeah
and
yeah
so
so
I
think
it's
it's
sort
of
in
your
it's
in
your
power.
If
you,
if
you
were
to
return
none
and
you
were
to
do
like
a
you
know
probability
sampler
like
that,
then
yes,
you
do.
You
do
run
the
risk
that
let's
say
the
first
trace
id
you
saw,
would
not
meet
your
probability
threshold
but
then
somewhere
in
the
middle
of
your
trace,
due
to
random
number
generation,
all
of
a
sudden,
a
new
trace
id
pops
up
and
it
does
meet
the
probability
threshold.
B
D
B
D
F
B
A
E
B
C
D
D
D
Being
timely,
we
already
know
the
specific
action
item.
The
there
is
one
specific
action
item
on
noah
correct
like
make
sure
the
trace
id
is
yes,
so
that
that's
already
passed
to
know
carrick
as
well.
Yeah.
D
Like
other,
like
issues
to
be
like,
oh
sorry,
I
just
closed
it
yeah.
So
we
need
to
fix
the
way
we
are
using.
It
properly
use
these,
and
there
was
another
thing
which
mike
already
proposed
in
this
pr
this
one,
along
with
everything
else,
which
was
for
a
way
to
run
this
like
get
activity,
data
request,
algorithm
for
spans
or
activities
created
outside.
D
So
I
don't
think
we
have
time
for
going
through
that,
but
for
now,
in
the
interest
of
time,
let's
just
assume
that
we
won't
need
it,
because
I'm
pretty
much
done
with
instrumentation
adapters,
and
it
has
this
hardcoded
sampler,
but
I'll
try
to
move
it
outside
of
instrumentation
adapters.
D
What
we
don't
really
want
is
instrumentation
to
be
aware
of
something,
so
allow
me
to
expand
one
more
day
to
see
if
we
can
like
move
it
away
and
see
like
michael-
and
I
can
still
discuss
this
more
afterwards
and
see
if
there
is
any
strong
reason,
then
let's
bring
it
up
in
the
next
meeting
and
then
take
it
from
there.
A
D
All
okay
yeah,
so
just
to
be
clear,
there
is
no
like
we
are
not
asking
for
a
new
api
change
from
dotnet.
Yet
based
on
the
discussion
here,
we
are
still
in
sync
with
spec
and
we
should
be
able
to
achieve
that
with
the
current
api.
We
are
aware
of
the
trace
id
and
I'm
it's
on
me
and
probably
michael,
can
help
whether
there
should
be
a
new
epa
for
running
external
activity
through
the
same
path
so
that
we'll
come
back
next
week
or
earlier.
D
Okay
I'll
put
this
in
the
notes,
I'm
very
valid
typing
when
I'm
talking
so
I'll
finish
this
and
then
type
this
thing:
okay,
yeah
thanks
a
lot
for
everyone.
It's.
D
We
discuss
in-depth
technical
things
in
dot
net
sake
compared
to
other
things,
but
yeah.
It's
good
that
we
are
solving
problems
right
here,
yeah,
so
michael
did
you
have
anything
else
to
discuss
or
you
can
just
wait
for
like
to.