►
From YouTube: 2021-11-04 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
Good
morning,
I'd
like
to
wait
to
see
if
we
get
atmar
today,
I
put
several
topics
in
the
notes
and
if
you
have
access,
please
add
your
name
to
the
attendees.
A
Hi
josh:
how
are
you
good
and
hi
peter?
I'm
glad
to
see
you
here
appreciated
your
questions
last
week
and
I'm
looking
forward
to
some
discussion
about
them.
A
So
maybe
in
one
more
minute
I
will
begin
talking
without
atmar
and
we
can
see
what
we
see.
A
While
I
wait
just
a
sec,
I'm
gonna
find
what
I
see
there
was
a
question
from
amazon.
People
are
interested
in
how
to
pick
up
remote
sampling.
A
It's
now
time
for
me
to
start,
I
think
so.
Thank
you
all
the
agenda
items
today.
Hopefully
we
can
talk
in
a
small
group
about
them.
My
draft
spec
pr
for
the
specification
and
my
hotel
go.
Implementation
are
up
and
ready,
and
basically
waiting
for
reviews.
A
I
did
get
some
feedback
from
yuri
who's
been
pretty
key
so
far
in
this,
but
as
I
skimmed
over,
it
was
mostly
editorial
about
the
text
of
my
my
writing
and
not
true
objections
to
what
we're
doing
so
I'll
work
on
the
the
editorializing
with
him.
The
topic
that
the
the
objection
that
came
up
or
the
sort
of
point
that
that
peter
listed
in
the
discussion
there,
however,
I
think,
is
really
important
and
actually
something
that
I
will
admit.
A
I
I
missed
in
the
back
all
the
back
and
forth
on
this
sampling
discussion.
So
I'll
summarize
it
and
then
maybe
peter
can
talk
with
us
about
it.
So
the
history
here
is
that
we
started
with
a
proposal
to
do
power
of
two
sampling
and
we
had
that
power
of
two
sampling
proposal.
A
But
there
there's
first
of
all
a
compatibility
question.
Our
existing
sampler
spec
and
many
of
the
existing
uses
that
we
know
of.
We
don't
think
there
are
very
many
uses
existing,
but
the
ones
we
do.
We've
heard
of
people
using
non-power
of
two
probabilities
and
that's
not
so
uncommon.
A
So
the
proposal
to
have
an
implementation
that
did
random
choice
between
the
two
nearest
powers
of
two
came
up
and
we've
we've
seen
that
work
and
we've
seen
the
math
correct,
is
correct
and
we've
seen
an
implementation
and
so
on,
and
the
reason
why
I
went
forward
with
that
is:
it
seemed
to
serve
ottmar's
purpose
from
the
dynatrace
use
because
they
are
actually
not
trying
to
find
complete
traces.
They
are
trying
to
make
estimates
from
partial
traces.
So,
for
the
way
dynatrace
intends
to
use
this
data.
A
It
was
okay
and
then
for
light
steps
purposes.
I
actually
am
not
super
interested
in
partial
sampling.
For
my
customers
we
want
root
based
probability,
sampling
with
adjusted
counts
and,
and
we're
going
to
tell
our
customers.
Please
just
just
do
this
at
your
root,
so
the
current
proposal
works
for
light
step,
but
I
didn't
really
real.
A
I
didn't
think
through
all
the
implications
of
offering
the
proposal
to
offer
non-powers
of
two
power
sampling,
because,
although
it
works
at
the
root,
it
doesn't
provide
complete
traces,
the
way
it
was
advertised
to-
and
I
think
it
leaves
us
with
some
complications-
and
I
think
I
understand
them-
but
it's
just
not
not
great,
and
I
think
the
two
points
that
peter
raised
are
connected.
So
I'm
gonna
try
and
explain
them,
and
then
we
can
let
peter
talk.
Hopefully.
A
So
the
idea
that
if,
if
we
are
limited
to
powers
of
two
and
we
are
doing
this
random
interpolation
between
the
powers
of
two,
let's
suppose
you
try
and
get
seventy-five
percent
sampling.
A
Well,
if
you
do
that
at
your
root,
you're
going
to
get
every
you
know,
some
of
your
traces
will
have
an
adjusted
count
of
one
and
b
complete
and
some
of
your
choices
will
be,
have
adjusted,
count
two
and
be
complete.
But
if
you
start
doing
75
sampling
in
the
middle
of
a
trace,
you
may
end
up
with
a
trace
that
is
incomplete
because
the
r
value
was
set
to
one
and
the
p
value
was
set
to
zero
or
something
like
that.
That's
the
other
way
around.
A
Well,
you
have
a
partial
trace.
Is
another
way
of
saying
that,
and
at
this
point
I
think
you're
able
to
say
something
like
traces
will
be
complete.
A
Meaning
how
do
you
know
when
a
trace
is
complete,
and
this
is
the
point
at
which
I
want
to
step
way
back
and
remind
us
that
open
telemetry
has
a
trace,
completeness
problem.
Even
before
you
talk
about
sampling,
we
don't
have
a
way
to
know
when
a
trace
is
complete
period
and
this
there
is
a
long
story
going
back
here.
A
When
open
telemetry
came
across
this
field
called
number
of
children,
they
reacted.
I
would
say
they.
I
was
there,
but
it
was
one
of
the
earliest
points
of
contention
for
the
stand
data
model,
which
is
how
are
you
ever
going
to
count
children?
It's
pretty
difficult,
especially
in
the
model
of
open,
telemetry
or
open
tracing
where
you
don't
actually
have
a
call
to
say,
create
child.
You
have
a
call
to
say,
create
context
or
create
child
context
and
then
creating
a
child.
A
Spam
may
happen
in
a
remote
environment,
and
so
the
first
question
was:
how
do
you
know
if
you
had
a
child
or
not?
You
don't
actually
get
that
signal
unless
there
was
some
sort
of
back
propagation
to
tell
you
whether
or
not
a
span
was
created,
and
then
you
could
do
some
special
casing.
A
So
at
the
point
when
we
were
now
evaluating
this
trying
to
get
the
trace
id
ratio
sampler
fixed
because
of
some
to
do's
and
getting
the
vendors
what
the
vendors
some
of
the
vendors
want,
we
realized
that
that
was
why
that
feature
had
been
part
of
open
census.
It
was
part
of
the
the
trace
completeness
story,
which
gets
definitely
gets
worse.
When
you
have
sampling
like
we're
talking
about,
but
it
doesn't,
it
doesn't
exist.
It
doesn't
exist
because
of
sampling.
It
exists
because
of
collection
infrastructure.
So
I've
spoken
a
lot
about
that.
A
A
A
That's
disconnected
in
the
current
open,
telemetry
data
model
and
that's
not
useful
and
one
way
you
could
figure
out
how
to
do
is
you
could
you
could
try
to
remember
which
parent
was
sampled
or
you
could
try
and
count
the
number
of
skips
and
something
like
that?
There's
all
kinds
of
ways:
we've
we've
approached
this,
but
it's
never
reached
the
point
of
being
an
actual
proposal.
A
Okay,
so
I've
spoken
about
how
trace
completeness
is
a
problem
and
if
we
try
to
get
75
sampling
in
the
current
scheme,
some
traces
are
going
to
be
incomplete
and
you'll
have
trouble
figuring
that
out.
It's
great
that
you
and
and
of
course,
when
you
are
a
parent,
when
you
are
a
child,
you
can
tell
if
you
have
a
missing
parent,
but
the
opposite
is
not
true.
A
So,
let's
not
turn
this
into
a
conversation
about
trace,
completeness,
it's
never
been
perfect
in
open,
telemetry
and,
and
we
might
want
to
talk
about
fixing
it,
but
I
don't
think
it's
necessarily
an
obstacle
with
sampling.
That
said
reeling
it
all
the
way
back.
If
we
have
75
sampling
configured
and
sometimes
it's
50
and
sometimes
100-
I
think
you
can
say
the
trace
will
be
complete
with
probability.
A
Well,
there's
some
there's
some
probability
statement
that
I
need
to
make,
and
I
I
always
say
I
can't
do
math
on
my
feet.
So
I
don't
want
to
make
it
right
now,
but
there's
some
probability
of
having
incomplete
trace
and
it
gets
worse.
The
more
nodes
are
involved
and
it
gets
worse.
A
The
closer
you
are
to
like
the
lower
power
of
two
or
something
like
that,
and
it
gets
better
the
closer
you
are
to
the
higher
power
of
two
or
something
like
that,
and
although
I
haven't
made
a
precise
statement,
my
gut
feeling
is
that
if
you're
say
trying
to
get,
you
know,
ten
percent
sampling
and
the
nearest
power
of
two
is
twelve
and
a
half
percent.
A
I
configure
ten
percent
sampling
and
I
can
say
that
that
some
percentage
of
my
stamp
of
my
traces
will
be
complete
if
there's
just
one
of
those
spans
and
then
the
more
of
those
spans.
I
add
to
my
trace
the
less
and
less
likely
I
am
to
have
a
complete
trace,
but
there's,
but
there's
some
sort
of
threshold.
Okay,
I
don't
do
math
on
my
feet,
so
I
can't
try
to
tell
you
what
that
is,
but
I
think
there
is
a
there's,
a
statement
we
could
make
here.
A
It's
pretty
complicated
and
it's
not
great
the
reason
why
I'm
trying
to
say
this,
though,
is
that
as
long
as
there's
a
statement
that
we
can
make
about
well,
as
long
as
the
probability
is
this,
then
you're
going
to
get
a
complete
trace,
then
there's
an
option
to
fix
this
with
the
next
bullet
point,
which
is
peter's.
Other
suggestion
point.
So
if
I
had
a
way
to
support
other
powers
of
two
like
or
arbitrary
values,
then
then
the
it
fixes
this
situation.
A
So
if
I
could
have
arbitrary
precision,
if
I
wasn't
limited
to
powers
of
two,
that
would
be
one
solution
and
the
other
solution
is
to
have
lots
of
powers
of
two
be
supported,
so
the
one
that
you
know
as
an
example
to
talk
through
it
if
square
root
of
two
over
two
that's
point
seven
or
something
like
that.
0.71
was
to
be
included.
That
would
be-
and
I
mentioned
in
the
slack
last
week-
there's
a
strong
connection
with
our
base.
A
2
histogram
work,
so
I
already
understand
this
number
scale
really
well
so
a
scale
one
histogram
in
that
work
would
correspond
with
a
sampling
regime
where
you
had
one
division
between
every
power
of
two
and
that
would
fall
at
square
root
of
two
over
two.
So
now
you've
got
a
power
of
2
over
2
sampling
probability,
and
if
you
want
to
configure
75
sampling
now
you
can
choose
between
square
root
2
over
2
or
100.
A
So
your
band
is
closer
now
and
I
I'm
I'm
wondering
if
that
helps
us
solve
this
problem.
If
we
can
make
that
band
small,
then
we
can
solve
this
problem.
I
think,
but
it
does
require
admitting
this
either
some
sort
of
extra
precision
or
scale
multiple
scale,
r
values,
and
I
see
how
to
make
it
work
from
working
through
the
histogram
but
we're
getting
complicated
here
anyway.
I
think
I've
overviewed
all
those
topics
and
I
try
to
connect
them
too,
and
I
appreciate
all
your
input
peter.
B
So
yeah
sorry,
so
you
mentioned
already
a
number
of
of
workarounds
for
this.
There
is
yet
another
one
which
I
would
like
to
mention.
Is
it's
not
ideal,
as
I
mentioned
on
the
in
my
remarks.
B
So
what
is
required
to
maximize
the
chances
of
getting
a
complete
trace
is
that
those
decisions
are
somewhat
synchronized.
Of
course
the
nodes
don't
talk
to
each
other,
but
they
share
the
trace
id.
So
if
we
run
a
hash
on
trace
id-
and
this
is
very
similar
to
the
old
trace
id
ratio
sampler
and
that
would
be
used
only
to
select
which
of
the
two
probability
thresholds
we
would
use,
we
would
get
better
chances
of
the
right
chances
of
getting
the
complete
span
now.
B
Of
course,
the
drawback
here
is
that
we
made
a
lot
of
effort
in
this
proposal
to
get
away
from
hashing
trace
id,
because
it's
not
portable
and
so
on.
So
this
this.
This
is
this.
This
particular
drawback
also.
B
A
A
I
actually,
I
think,
that's
the
that's
the
best
work
around.
We
can
it
in
as
much
as
it
gives
us
the
power
we
were
looking
for
at
the
root
without
breaking
things,
and
then
I
could
imagine
respect
just
saying
you
should
not
use
power
2.
and,
and
it
allows
you
to
do
it.
A
If
you,
if
you
care-
or
I
don't
know
why
you'd
do
it-
I
mean
atmar's
solution
here,
uses
this
partial
trace
logic
and-
and
I
think
he
will
be
happy
with
the
situation,
and
I
know
that
if
I
was
just
characterizing
spans
and
and
not
trying
to
get
complete
traces,
essentially
just
using
span
data
for
metrics,
then
sampling
those
spans
interior
at
an
interior
span
with
a
non
power.
Two
fractional
sampling
rate
will
work
for
me.
I
can
count
spans
still.
I
just
can't
find
complete
traces.
A
Therefore,
it
may
be
a
should
recommendation,
not
a
must
recommendation,
because
there
are
there
are
uses
here.
It's
just
that.
You
don't
have
a
way
to
detect
completeness
and
if
we
ever
get
to
a
proper
solution
for
completeness
and
open
telemetry,
then
then,
then
you
could
say:
if
you
really
want
to
have
those
between
powers
of
two
fractional
sampling
opportunities.
You
can
do
that
and
you
just
you,
have
to
check
for
complete
traces
and
they'll
be
incomplete,
so
often
which
there's
some
formula
or
something
like
that.
We
could.
We
could
write
down.
B
B
B
A
Interesting
universal,
so
let's
see
that
the
idea
is
to
let
the
trace
id
hash
consistently
choose
between
the
upper
and
the
lower.
A
I
like
it,
do
I
like
it.
A
I
guess
there's
this
other
idea
of
allowing
fractional
powers
of
two.
I
like
it
only
because
I
just
worked.
It
worked
through
it
for
the
histogram,
but
I
think
it
would
probably
blow
people's
heads
up
and
people
would
find.
B
Very
difficult,
yes,
my
point
that
I
made
at
the
slack
channel
was
that
we
have
some
other
ways
to
define
these
thresholds
and,
as
a
matter
of
fact,
when
we
have
only
62
values,
we
can
pick
those
thresholds
arbitrarily
and
it's
not
a
huge
maintenance
cost
to
have
just
a
static
table
of
these
thresholds,
hard
coded.
B
B
A
Yeah
and
so
then
the
idea
is
that
if
you
had
a
so
much
like
the
proposal
to
have
fractional
powers
of
two,
there
would
be
an
alternate
table,
essentially
an
alternate
mapping
from
r
to
to
just
r
and
p.
I
guess
I
would
have
to.
A
More,
I
I
liked
the
idea
in
as
much
as
well
I'm
trying
to
say
it
allows
extension
like
you
could
add
something
like
fractional
positive
2
on
top
of
what
we
have,
and
I
think
you
could
define
you
could
define
it
in
a
way
that
was
backwards
compatible
well
compatible,
maybe
not
backwards
compatible.
A
So
if
the
root
was
using
skill,
one
meaning
to
support
that
power
of
two
over
two
fractional
sampling
rate
and
and
all
the
other
nodes
weren't
you
can,
you
can
down
scale
and
you
can
you
can
handle
it
correctly
if
the
if
the
interior
spans
aren't,
aren't
expecting
that
you
can
change
the
the
scale
one
or
value
down
to
a
scale,
zero,
r
value
or
something
like
that.
A
B
A
B
No
not
really
because
because,
let's
face
it,
the
problem
probability
is
75
doesn't
make
a
lot
of
sense
right.
I
I
cannot
imagine
that
somehow
who
understands
what's
going
on
would
choose
such
such
a
number?
It's
stupid,
so
yeah.
No,
it
was
just
a
discussion,
more
theoretical
discussion.
It's
I.
A
See
good,
okay,
I'm
glad
to
hear
that
and
it
sounds
like
the
two
most
practical
outcomes
of
this
are
either.
A
We
just
recommend
avoid
the
problem
by
choosing
non-powers
of
two
only
at
the
root
and-
and
then
just
word
your
way
out
of
that
by
saying
you
shouldn't
do
this,
unless
you
know
what
you're
doing
and
you
can,
but
you
shouldn't
or
at
that
moment
where
we
are
deciding
to
between
two
powers
of
two
just
to
use
a
hash
and
then,
of
course
we
are
aware
of
statistically
speaking,
I
think
that
that
worries
some
people
hashing
is
never
going
to
be
very
reliable
from
a
statistical
standpoint.
A
A
It's
also
an
option
that
could
be
chosen
by
the
user
without
a
great
deal
of
I
just
don't
want
to
add
more
environment
variables
or
more
options.
But
honestly
you
could
have
one
implementation
decide
yeah,
I'm
going
to
use
that
hash.
I'm
going
to
hash
the
trace
id
to
decide
between
the
two
and
the
other
could
decide.
I'm
going
to
do
random
choice,
decide
between
the
two
and
one
will
have
better
statistics
and
one
will
have
better
completeness
that
doesn't
that
seems
like
both
are
possible
to
me.
A
That's
a
nice
option.
That's
a
nice
realization.
A
So
I
think
I
I
have
to
think
about
this
more.
I
want
to
see
I'd
like
to
see
what
atmar
thinks,
just
because
he's
been
involved,
the
whole
time
I
it
seems
like
there
are
two
options
and
they're
both
reasonable.
A
And
perhaps
we
could
just
document
both
or
leave
an
option
open,
as,
as
you
know,
I'm
trying
to
specify
this
as
an
optional
sampler
so
that
we
don't
force
everyone
in
the
open
telemetry
to
implement
this
right
away.
One
thing
we
can
one
reason
to
do
that
is
to
just
delay
and
say
this
option
can
support
both
until
we
figure
out
what
users
actually
want.
That's
one
thing
we
could
do
anyway,
peter
you've
been
full
of
really
great
suggestions,
and
I'm
appreciating
the
insight.
So
thank
you.
A
I
would
be
glad
to
at
least
write
down
based
on
this
discussion
in
my
pr
I'll
work
on
this
warnings
about
what
about
what
we
just
discussed
and
probably
at
this
point,
I'm
leaning
towards
the
simpler
option,
which
is
just
to
say,
advising
against
non-powers
of
two
for
interior
spans
and
warning
about
what
will
happen
if
you
do
and
then
maybe
this.
A
This
is
what
I'd
put
in
like
a
other
ideas
considered
or
future
work
or
caveats
is
like
there's
one
other
way.
You
could
just
decide
to
do
this,
which
is
to
instead
of
using
a
random
number
use
a
deterministic
number
from
hashing
trace
id,
and
then
you
can
choose
your,
which
will
which
will
change
your
statistics,
but
not
change
your
interface,
and
it
doesn't
change
very
much
at
all
so
they're
both
good
options.
I
feel
like
it's
really
helpful.
I
appreciate
your
input
a
lot.
B
A
A
A
I
would
be
glad
to
say
I
will
just
try
and
reflect
this
discussion
in
a
new
section
of
our
spec.
If
enough
people
respond
with
yeah.
That's
that's
a
good
point.
Completeness
is
still
broken.
We
should
fix
this.
Then
I,
like
your
idea,
a
lot
peter.
I
guess
I'm
trying
to
say
I
think
we've
beaten
this
topic
up
right
now
and
I
don't
know
if
I
have
another
one
for
us
to
talk
about.
A
I
do
know
that
amazon
and
the
red,
the
jaeger
project
are
both
kind
of
waiting
or
looking
for
guidance
on
how
to
get
remote,
configurable
sampling
into
hotel
and
I'm
what
I'm
going
to
do
is
recommend
them
to
to
come
next
week
and
put
something
on
the
agenda.
So
we
can
talk.
A
I
haven't
been
driving
that
myself,
it's
not
something
that
my
vendor
is
eager
super
eager
for,
although
every
customer
kind
of
wants
this
in
the
end,
it's
just
that
it's
not
high
priority
for
us,
so
maybe
that
can
be
next
week
and
if
you
are
here
from
one
of
those
companies
who
is
interested
in
that,
please
show
up
or
talk
to
us
on
slack.
I
know
who
I
know,
who
else
is
interested
in
it.