►
From YouTube: 2021-09-09 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
Okay,
it's
not
coming
where
the
sampling
efforts
seem
to
be
moving
in
in
a
way
that
makes
me
think
not
many
people
are
going
to
come
to
this
meeting,
I'm
going
to
project
our
notes,
and
maybe
we
can
just
talk
through
it
quickly
and
then
be
done
since
I
got
feedback
from
yuri
last
night,
which
makes
me
feel
like
I
can
move
forward
and
it's
a
small
group
we
might
as
well.
So
I'm
so
tired
of
eight
o'clock
meetings.
Everybody!
A
Okay
here
are
our
notes.
I,
since
since
there's
something
on
the
agenda-
and
I
talk
about
my
oteps
all
the
time.
I
would
love
to
not
talk
about
them
and
just
talk
about
what
else
is
on
the
agenda.
A
Would
nev
or
will?
Would
you
like
to
discuss
sampling,
it's
a
small
group,
but
I'd
be
happy
to
learn
what
is
on
the
agenda.
The
remote
sampler
design
dock.
C
Yeah,
this
is
something
I
posted
on
behalf
of
onoraga
and
aws.
C
I
think
that
you
left
some
feedback
on
it
offline
on
the
github
issue,
josh,
which
I
appreciate
it
and
I
just
generally
wanted
to
see
if,
if
there
was
any
kind
of
discussions
about
formalizing,
remote
sampling
in
in
otep
or
any
other
thoughts
on
that,
since
I
I
joined
the
sampling
sig
a
few
weeks
ago
and
I've
been
busy
since
then,
but
it
was
mainly
discussions
about
euroteps
which
were
kind
of
probability-based
sampling
and
how,
to
you
know
propagate
the
sampling
probability
across
services,
but
it
wasn't
really
about
how
the
samplers
themselves
were
to
be
yeah,
checked
out
so
yeah.
A
See
I'm
gonna
try
and
summarize,
where
I
think
you've
where
this
look
is
right
now,
so
we've
been
talking
about
probability
sampling
for
months,
maybe
a
long
time,
and
that
the
goal
there
is
is
to
upgrade
the
specified
samplers
to
get
to
where
we.
If
you
choose
one
of
the
built-in
samplers.
Therefore,
today
you
would
get
known
probability
for
all
of
your
chases.
A
If
everybody
in
the
in
the
chase
was
upgraded
to
this
latest
spec
and
then
there's
so
that
that
conversation
has
been
moving,
I
think
it's
actually
coming
to
a
close
and
I'm
happy
where
with
where
it
is,
and
the
other
half
of
sampling
discussion
has
been
about
how
to
configure
sampling
and
that
turns
into.
As
I
see
it,
essentially
a
rule-based
approach
for
deciding
at
runtime
based
on
the
attributes,
you
have,
in
your
hand,
which
probability
to
use
or
which
of
the
built-in
samplers
to
use
which
turns
into
a
probability
sampling
decision.
A
And
among
the
participants,
we
have
two
candidates
for
that
type
of
system:
there's
the
jaeger,
remote
sampling
and
then
there's
what
x-ray
has
done,
and
I
have
seen
both
and
I
am
expecting
that
these
two
kind
of
converge-
but
I
have
not
been
offering
to
lead
that
because
it's
not
an
area
where
I
have
a
standing
really,
I
I
see
jaeger's
remote
sampling
and
I
see
x-rays,
remote
sampling
and
it
looks
like
they
could
fit
together
pretty
well
and
the
way
I
imagine
this
works
is,
you
know,
there's
some
separate
mechanism
in
the
sdk
that
will
contact
the
remote
source
to
get
the
sampling
configuration
and
that
can
be
updated
periodically
or
whatever.
A
A
What
I
need
for
probability,
we're
all
we're
all
happy,
and
this
essentially
suggests
that
for
remote
sampling
configuration
we
would
essentially,
I
would
say,
spec
out
a
a
configuration,
and
this
is
where
this
always
ends
up
as
a
configuration
question,
and
I
think
hotel
has
a
bigger
question
about
configuration
than
even
just
sampling,
which
is
part
of
the
reason
why
this
ends
up
being
stalled
and
that's
part
of
the
reason
why
ted
keeps
coming
this
meeting,
because
at
the
end
of
the
day,
it's
not
about
sampling
anymore.
A
It's
about
configuration,
and
I
don't
know
I
want
to
open
it
up
to
to
you
to
see
what
you
think
or
what
you
think
we
should
should
do
so
that
I'm
not
just
talking.
C
Yeah,
I
I
think
that
makes
a
lot
of
sense
and
I
was
not
exactly
sure
where
the
sig
was
at
in
terms
of
the
the
role-based
sampling,
because
that
was
something
that
I
noticed
was
kind
of
absent.
From
just
probability.
Based
was
also
kind
of
sampling
based
on
service
name,
and
you
know
like
url
path
or
whatever
else,
attributes
that
we
have,
and
so
that's
something
that's
kind
of
fundamental
to
x-ray
sampling
and
so
yeah.
C
A
A
It
says
that
sdks
may
provide
an
implementation
of
the
jager
sampler,
which
is
named
jaeger,
remote,
and
that
just
means
specifying
that
legacy
protocol,
which
is
a
very,
very
simple
protocol.
Where
you
you
hit
the
collector
on
a
slash
sample
uri.
I
think,
and
it
gives
you
back
of
some
yamo
or
something
similar
json
proto.
I
can't
I
don't
remember
which
and
and
then
you
go
and
you
execute
those
rules.
So
there's
a
configuration
language
that
jager
has,
and
it
is
very
much
based
on
attribute
value
pairs.
Predicates.
Essentially
I've
seen
what
what
x-ray
has.
A
I
think
it's
a
bit
more
sophisticated
and
whenever
we
have
these
conversations,
another
sort
of
corner
case
gets
discussed,
which
I
try
to
try
to
stay
away
from.
But
it's
this
quarter
case
about
rate
limited
sampling.
It's
like
both
jaeger
and
x-ray
have
a
way
to
set
the
policy,
and
the
policy
can
be
probability
or
it
can
be
rate
limited
and
for
rate
limited
sampling.
A
I
just
use
a
phrase
view
configuration
which
may
sound
completely
new,
but
it's
coming
out
of
a
metrics
spec
world
where,
because
metrics
started
as
a
less
mature
signal-
and
there
was
less
of
an
ecosystem
to
adopt
off
the
shelf
like
there
was
with
open
tracing,
we
came
in
with
open
census,
essentially
wish
list
for
metrics
sdk
and
the
wish
list
for
metrics
sdk
was
you
can
configure,
which
metrics
will
report,
which
one
which
aggregations
you
will
use,
which
ones
will
not
report
and
so
on,
and
that,
for
all
you
know
intents
and
purposes,
is
essentially
a
way
to
configure
what
you
see
when
you
run
the
metrics
sdk
and
what
people
are
asking
for
with
tracing
is
I
want
to
configure
what
I
see
and
and
part
of
that
is
expressed
as
a
sampling
decision.
A
So,
whereas
metrics
went
in
one
direction,
which
is
we're
going
to
spec
out
a
view
configuration
before
we
get
to
1.0
and
it
was
hard
and
it's
not
even
sure
that
we're
done,
whereas
tracing
just
sort
of
made
a
run
around
sampling,
it's
an
arbitrary
api.
You
can
have
to
configure
your
tracing,
but
as
a
result,
we
have
no
standard
or
any
kind
of
shared
language
for
configuring
traces
now.
So
I
I
keep
saying
to
the
tracing
group
or
the
group
at
large.
We
should
talk
about
trace
view.
A
Configuration
turns
into
sampling
configuration,
it
turns
into
configurable
tracing
selection
policies,
which
then
you
might
really
just
want
to
do
remotely,
because
we
all
understand
why
the
decision
should
be
centralized
so
to
break
this
down.
We
have
essentially
two
more
parts.
One
is
there's
a
way
to
configure
which
samplers
get
applied
based
on
evaluation
of
predicates
like
and
they
could.
A
They
may
be
ordered,
and
this
is
where
the
metrics
view
group
got
a
little
bit
slowed
down,
is
like
what's
the
order
of
evaluation,
and
when
do
you
stop
evaluation
and
are
their
priorities
and
if
you've
ever
dealt
with
like
male
handling,
filter
rules,
it's
the
same
type
of
problem.
It's
complex
working!
It's
a
complex
solution
space
where
you've
got
these
predicates
that
are
going
to
be
applied
and
at
some
point
you're
going
to
stop
evaluation
and
just
choose
the
one
you
chose,
and
I
don't
know
it's
not
a
problem
about
telemetry
anymore.
A
You
can
see
what
what
jaeger
has
and
what
aws
has,
and
I
think
we
should
just
try
and
find
the
middle
ground
there.
I
don't
think
anyone's
working
on
it
unless
onorak
knows
of
someone
who's
been
trying
to
kind
of
reconcile
the
x-ray
with
the
jaeger.
I
I
think.
C
Go
yeah.
No,
I
mean
that's,
that's
the
direction
that
that
we
want
to
go
as
well
like
we
we've
implemented.
Obviously,
onorag
implemented
the
remote
sampling
algorithm
for
x-ray
for
the
java
sdk
in
open
telemetry
and
basically
before
we,
it
is
pretty
complex.
It's
a
pretty
convoluted
components
that
you
have
to
add
and
stuff
behind
the
sampler
interface,
and
we
just
want
to
kind
of
you
know
codified
in
the
spec
and
like
get
some
agreement
with
the
with
jaeger
who's.
C
The
only
other,
like
you
said,
remote
sampler
that
we
know
of
and
basically
make
sure
that
when
we
go
ahead
and
take
this
effort
on
in
other
languages,
that
will
have
some
semblance
of
you
know
robustness
so
that
you
know
we
can
say
oh
yeah,
this
is
you
know.
This
is
a
thing
that
the
community
approves
of
that
we're
doing,
and
this
isn't
like
some
abuse
of
the
sampler
interface,
where
we're
just
like
stuffing
a
bunch
of
proprietary
logic
behind
it.
You
know.
A
Yeah,
I
definitely
want
to
avoid
that
feel
because
I
think
everyone
wants
configurable
sampling
views.
I
keep
saying
it,
and-
and
people
are
going
to
be
wary
of
this
hoisting
in
a
big
thing
that
something
you
know,
platform
provider
wants
and
and
hasn't
really
gone
through
a
community
kind
of
process.
A
I
pulled
up
the
the
what
we've
done
in
the
metrics
sdk
work
recently,
so
this
is
part
of
the
sdk
spec
and
there's
there's
some
to-do's
here
that
we're
currently
working
on
this
is
the
area
of
this
spec
that
was
so
hard
and
took
the
most
work.
A
So
it's
everything
from
this
view
section
down
it's
two
and
a
half
pages
or
so-
and
this
is
where
we
at
least
drafted
a
set
of
rules
for
in
the
configuration
and
then
you
can,
you
can
say
a
list
of
essentially
rules,
and
this
is
selection
criteria,
and
these
are
all
the
things
that
you
might
select
based
on,
and
so
you
can
imagine
for
the
trace
world
doing
exactly
the
same
thing
expands
have
names,
they
have
attributes,
they
have.
They
have
instrumentation
library,
they
have
a
few
other
static
properties.
A
Anyway,
you
can
see
this.
I
don't
want
to
read
it
right
now,
but
you
can
see
what
the
the
bar
was.
It
was
hard,
and
so
I'm
not
saying
this
would
be
easy,
but
I
think
this
is
the
direction
and
and
then,
if
we're
lucky
the
end
of
the
day,
all
you
have
is
a
giant
configuration
problem
and
and
we're
facing
that
down
right
now
in
open,
telemetry,
it's
bigger
than
metrics
and
traces,
it's
more
like
the
the
number
of
environment
variables
is,
is
out
of
control.
A
The
desire
for
a
struct
that
contains
all
the
fields
in
some
kind
of
structured
way
like
json
or
yaml,
is
really
strong
right
now.
So
we're
we're
starting
to
look
at
that
and
I
think
it'll
end
up
there
and
there'll
be
a
whole
section
of
parsing
a
configuration
file
and
deciding
how
to
apply
it
to
produce
an
sdk
configuration
and
it'll
be
bigger
than
metrics
and
traces.
Yeah.
A
A
I
would
I
think
concretely
the
way
to
move
this
forward
is
to
get
I
mean,
anarch
seems
to
know
more
than
I
do
about
details
than
you
do
too,
but
the
jaeger,
remote
sampler
has
been
discussed,
and
in
this
very
meeting
two
months
ago
I
expressed
fear
that
if
we
specified
the
name
jaeger
remote,
that
the
jaeger
remote
sampling
would
become
a
de
facto
standard
and
ted
told
me,
I
was
being
hyperbolic
and
I
should
stop
saying
that
I
don't
think
he's.
I
think,
he's
probably
right.
A
I
was
being
hyperbolic,
but
there's
definitely
a
a
precedent
in
jager
to
do
exactly
what
jaeger's
doing
and
x-ray
is
not
quite
the
same,
and
I
think
what
you
should
do
is
take
the
two
study
them
and
then
look
at
how
to
bring
that
into
an
open
tomato
world
because,
for
example,
the
extra
the
jaeger
settings
have
a
few
hard-coded
names
which
will
map
into
conventional
fields
like
operation.
A
D
Yeah,
I
know
ted
was
talking
about
it's
part
of
the
sig
defining
effective,
remote
updating
of
config,
but
here
I've
got
it.
I'm
gonna,
I'm
gonna
share
right
now
what
I've
got?
Where
did
that?
Go.
A
So
this
is
the
yaeger's
sampling
config
and
much
like
the
views
for
metrics.
I
just
showed
you
you've
got
a
rule
and
then
a
default
strategy.
So
the
types
probabilistic
I
think
there
are
a
few
other
types
and-
and
I
mentioned
rate
limit
as
being
a
concerning
one,
but
we
can
handle
that.
That's
the
only
problem
service
name
is
a
and
then
for
each
operation,
so
you
can
choose
based
on
service
and
operation,
and
I
and
I
don't
know
how
you
use
labels
or
attributes,
but
I
think
that's
part
of
it
too.
A
So
there's
more
there's
more
flexibility
than
just
this
example,
and
I
know
that
the
x-rays
configuration
file
is
if
I
squint
or
kind
of
the
same.
It's
not
it's
not
the
same,
but
it's
close
right.
So
what
I'm
saying
is
we
should
standardize
these
and
it's
going
to
be.
A
I
think
an
otep
would
probably
be
a
great
place
to
start
and
I
don't
think
anyone
else
has
written
that
otp,
comparing
the
two
trying
to
find
the
common
elements
and
then
recasting
them
in
terms
of
hotel
semantic
conventions
so
that
we
say
service
and
span
name.
I
mean
I
think
operation.
Everyone
knows
what
operation
name
means
here,
but
we
don't
use
that
name
as
much
in
open
telemetry
and
then
probabilistic.
A
The
idea
is
that
type
would
map
into
one
of
our
built-in
samplers
so
and
and
trace
id
ratio
is
what
we've
been
calling
it.
I
there
was
a
piece
of
feedback
in
my
most
recent
iterations
saying:
let's
not
use
that
name
anymore,
and
I
think
maybe
that's
true,
but
I
don't
know
what
to
call
it
yet.
Consistent
probability
is
probably
the
answer
anyway.
A
It's
this
rate,
limiting
that
I
that
I'm
objecting
to
for
hotel-
and
it's
not
that
I
don't
think
we
should
have
rate
limiting
it's
the
mechanism
that
I
that
I
object
to,
because
it
anyway
that's
that's,
that's
esoteric.
We
don't
have
to
talk
about
that
here.
Well,
it's
just
three
people
I'd
be
happy
to
answer
questions
and
help
guide
these
efforts
for
remote
sampling.
C
Yeah
no,
I
I
move
forward
generally
agree
and
I
I'm
definitely
going
to
try
to
track
down
somebody
who
is
in
authority
on
jaeger,
tracing
or
jager,
remote
sampling
and
yeah.
I
think
the
only
thing
like
you
mentioned
is
like
if
there
is
eventually
a
yaml
file,
I
think
a
necessary
addition
to
that
configuration
is
a
way
to
update
it
remotely
because,
obviously
we
want
to
avoid
having
just
a
single
like
local
file,
that
we're
reading
from
for
the
sampling
configuration
to
distribute
the
decisions,
especially
for
right,
limited
sampling.
So
the.
A
Metrics
view
config
spec.
Well,
it
doesn't
really
talk
too
much
about
config.
It
just
talks
about
what's
possible,
it
doesn't
talk
about
how
to
configure
it.
The
view
for
metrics
does
have
a
statement
and
it
came
from
riley
at
microsoft.
Basically,
because.
A
Wants
to
do
dynamic,
updating,
and
so
it
says
you
may
and
the
reason.
Why
is
that
we
don't,
I
think,
at
open
telemetry
across
the
entire
project
want
to
say
you
must
implement
dynamics,
configuration
updates,
and
it's
just
because
we
know
that
dynamic
configuration
updates
opens
a
can
of
worms.
That's
like
quite
wormy,
and
it's
so
much
simpler
to
do
static
configuration.
So
we
have
not
taken
a
step
to
say
all
hotel.
Sdks
must
implement
dynamics,
dynamic,
reconfiguration.
A
It's
just
saying
that
anyway,
you
can.
You
can
look
at
the
way
it's
specced
out
in
views.
It's
it's
made.
An
optional
thing
certainly
wouldn't
object
to
it,
but
we're
trying
to
set
the
bar
lower
lower.
I
think.
C
Yep
and
that
that
I
think
totally
makes
sense
because
it
is
quite
tricky
in
our
experience
and
maybe
we
would
only
even
define
parts
of
the
configuration
to
be
dynamic
where
it
makes
sense.
C
Really
hard
to
change
and
some
things
are
pretty
easy
to
change,
yeah
yeah,
so
that
that
seems
like
a
reasonable
place
to
fit
in
this
whole
remote
sampling
idea
so
yeah.
I
I
think
that
makes
sense
to
me
as
a
place
to
start.
Do
you
actually
have
anybody
any
like
contacts
who
you
would
say
or
like
three.
A
Jager,
so
yuri
shiguro
is
the
kind
of
lead
there
and
he
sometimes
comes
to
this
meeting
and
he's
been
the
kind
of
chief
critic
and
or
supporter
of
my
work
on
probability
sampling.
So
I
think
he's
the
right
at
least
the
right
person
to
ask
that
same
question
short
of
doing
some
research
on
the
yeager
teams
that
I
don't
actually
know
like
who
wrote
this
page
but
yeah.
We
should
ask
yuri
he
he
might
be
reachable
through
slack
or
he
shows
up.
A
I
can
ask
him
if
I
see
him
before
we
get
the
answer
to
this
in
one
of
our
meetings.
D
And
if
we
want
dynamic
capabilities,
we
define
in
that
the
ability
to
broadcast
or
have
callbacks
or
something
so,
therefore,
for
sampling
and
metrics,
they
define
their
own
set
of
config
because
they
are
unique
to
the
individual
components.
So
metrics
has
the
view
and
sampling
will
have
the
sampling,
config
and
all
the
rules
associated
with
it.
A
Yeah
the
spec
language
that
riley
wrote
about
updating
it.
I
just
just
reiterate
what
I
said.
I
think
that
you
talked
about
configuration
store.
A
I
think
that
would
be
a
valid
way
to
implement
this,
these
two
paragraphs,
but
but
the
idea
that
it
may
provide
methods
to
plate
if
it's,
if
it
provides
an
update
method,
it
should
apply
to
all
you
know
a
little
bit
of
structure
here,
but
in
other
words,
you
should
be
able
to
if
you're,
if
you're
going
to
apply
configuration
updates,
they
should
apply
retroactively.
As
all
this
says,.
D
Yeah
and
because
if
for
each
area,
it
would
have
to
define
which
configs
could
be
changed
dynamically
if
at
all,
because
yeah,
as
you
say,
there's
some
things,
you
are
just
too
hard
to
change.
Yeah.
A
So
sounds
like
well,
I
can
go
update
our
notes.
We
are
talking
about
remote
sampling
configuration
and
it
would
be
nice
to
move
forward
with,
essentially
a
maybe
a
shared
proposal
that
kind
of
encapsulates
what
jager
and
x-ray
are
doing
and
naming
the
essentially
a
composite
sampler,
which
would
boil
down
to
those
built-in
samplers
based
on
you,
know,
predicates
and
stuff.
A
I'm
very
supportive
of
this,
and
I
think
the
more
we
start
to
call
this
trace
views
it'll
the
more
successful
it'll
be,
but
I
may
be
wrong
about
that.
D
A
Will,
or
are
you
would
you
like
to
take
initiative
here
to
to
get
in
touch
with
someone
from
jaeger?
If
I
can
help
find
their,
I
mean
I
think
yuri
is
the
right
person
and,
and
the
other
person
that
I
that
comes
to
mind
is
oh
gosh
pavel.
I
have
to
remember
his
last
name
after
this
meeting
I'll
go
dig
up
a
few
names
for
you
and
I'll
slack
them
to
you.
Well,
because
I
know
the
other
person's
name,
I
just
have
to
think
of
a
last
name.
A
All
right
sounds
good.
I
will
direct
some
people
to
you,
will
and
and
see
if
we
can
make
some
progress
through,
maybe
an
otep
to.
I
think
that
the
not
the
the
entire
group
across
open
telemetry
does
not
know
what
x-ray
sampling
can
do.
It's
it's
people,
people
a
few
people
know,
but
not
everyone
knows,
and
I
think
it
would
help
just
to
expose
what's
possible
there,
aligned
with
jaeger,
especially.
C
Definitely
yep,
that
is,
that
is
our
goal,
so
I
would
definitely
appreciate
getting
forward
with
those
names,
and
hopefully
we
can
work
on
an
attempt,
together
with
them.
C
I
wrote
some
notes
on
the
sampling
sig,
which
were
partially
just
like
my
own
notes.
C
A
I
will
go
into
the
notes
and
see
what
see
what
you
wrote
and
see
if
I
can
anything
and
then
just
before
we
hang
up,
let's
see
if
I
can
find
anything.
A
D
Yeah
all
right,
I
guess
moving
forward,
I'm
quite
interested
in
looking
at
the
this
generic
config
and
remote
dynamic,
updating,
okay
for
microsoft.
Obviously
yeah.
A
Well,
I
think
this
this
is
instrumentation
sig,
that
ted's
been
promoting
he's
been
kind
of
coming
to
all
the
sticks
to
to
make
sure
everyone's
talking
to
everyone
else.
But
this
instrumentation
sig
is
is
a
kind
of
new
idea,
but
it's
really
that
there's
sort
of
a
complimentary
effect
where
you
need.
You
need
to
have
a
way
to
configure
each
library
of
instrumentation
until
you
have
that
way
to
configure.
A
It
was
just
like
the
number
of
options
is
too
many
and
it's
hard
for
users
to
get
what
they
want.
So
the
the
idea
of
instrumentation
is
sig
is
to
connect.
The
two
ends
of
the
problem
is
that
we
need
to
have
a
way
for
a
package
of
instrumentation
to
be
written,
and
then
we
need
a
way
to
configure
the
entire
package
and
it
comes
down
to
not
just
a
way
to
spec
out
these
views
and
how
to
update
them
and
so
on,
but
also
a
way
to
essentially
be
idiomatic
in
each
language.
A
A
I
think
that's
is
that
right.
Is
it
the
same
time?
Okay,
so
that's
why
we're
having
a
few
attendance
issues
all
right
so
we'll
we'll
work
on
that?
I
think
we're
basically
at
the
end
of
the
probability
sampling
work,
and
maybe
we
should
merge
this
into
configuration
and
instrumentation
yep
all
right
sounds
good.
Thank
you.
Both
I'll
send
some
slacks
will
and
I'll.
Let
you
keep
you
updated
now.